Что такое авторизация в браузере

Обновлено: 06.07.2024

В этой статье рассказывается, как IIS выполняет аутентификацию клиентов браузера.

Исходная версия продукта: Internet Explorer
Исходный номер базы знаний: 264921

Обзор

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

Методы проверки подлинности, доступные для Windows NT 4.0

Анонимный — вход в систему не требуется, и любой может получить доступ к данным, защищенным с помощью этого метода. Сервер использует встроенную учетную запись (IUSR_[имя компьютера] по умолчанию) для управления разрешениями на файлы. Браузер не отправляет никаких учетных данных или информации о пользователе с этим типом запроса.

Поддерживаемые браузеры: любые
Ограничения: нет
Требуются права пользователя: учетная запись анонимного пользователя, определенная на сервере, должна иметь разрешения на локальный вход.
Тип шифрования: нет

Базовый (открытый текст) — сервер запрашивает у пользователя вход в систему, и в браузере появляется диалоговое окно, позволяющее пользователю ввести необходимые учетные данные. Эти учетные данные должны совпадать с учетными данными пользователя, определенными для файлов, к которым пользователь пытается получить доступ.

Поддерживаемые браузеры: любые
Ограничения: небезопасно. Пароли легко расшифровываются.
Требуются права пользователя: учетная запись пользователя должна иметь разрешение на локальный вход.
Тип шифрования: кодировка Base 64 (не настоящее шифрование)

Запрос/ответ Windows NT. Сервер запрашивает у пользователя вход в систему. Если браузер поддерживает Windows NT Challenge/Response, он автоматически отправляет учетные данные пользователя, если пользователь вошел в систему. Если домен, в котором находится пользователь, отличается от домена сервера или если пользователь не вошел в систему, появится диалоговое окно с запросом учетных данных для отправки. Windows NT Challenge/Response использует алгоритм для создания хэша на основе учетных данных пользователя и компьютера, который использует пользователь. Затем он отправляет этот хэш на сервер. Браузер не отправляет пароль пользователя на сервер.

Поддерживаемые браузеры: Internet Explorer версии 3.01 и выше

Ограничения: требуется двухточечное соединение. Обычно цепь закрывается после сообщения об ошибке «401 неавторизованный»; однако при согласовании последовательности проверки подлинности Windows NT Challenge/Response (которая требует нескольких круговых обходов) сервер сохраняет цепь открытой на протяжении всей последовательности после того, как клиент указал, что он будет использовать Windows NT Challenge/Response. Прокси-серверы CERN и некоторые другие интернет-устройства не позволяют этому работать. Кроме того, Windows NT Challenge/Response не поддерживает олицетворение с двойным переходом (в том смысле, что после передачи на сервер IIS одни и те же учетные данные не могут быть переданы на внутренний сервер для проверки подлинности).

Требуются права пользователя: учетная запись пользователя, которая обращается к серверу, должна иметь разрешение «Доступ к этому компьютеру из сети».

Тип шифрования: хэш-алгоритм NTLM, который также не закодирован.

Порядок приоритета. Когда браузер делает запрос, он всегда считает первый запрос анонимным. Поэтому он не отправляет никаких учетных данных. Если сервер не принимает анонимный ИЛИ если анонимная учетная запись пользователя, установленная на сервере, не имеет разрешений на запрашиваемый файл, сервер IIS отвечает сообщением об ошибке «Отказано в доступе» и отправляет список типов проверки подлинности, которые поддерживаются с помощью один из следующих сценариев:

Если Windows NT Challenge/Response является единственным поддерживаемым методом (или если анонимный вызов не работает), то браузер должен поддерживать этот метод для связи с сервером. В противном случае он не сможет договориться с сервером, и пользователь получит сообщение об ошибке «Отказано в доступе».
Если единственным поддерживаемым методом является базовый (или если анонимный не работает), в браузере появляется диалоговое окно для получения учетных данных, а затем эти учетные данные передаются на сервер. Он пытается отправить эти учетные данные до трех раз. Если все это не удается, браузер не подключен к серверу.
Если поддерживаются как Basic, так и Windows NT Challenge/Response, браузер определяет, какой метод используется. Если браузер поддерживает запрос/ответ Windows NT, он использует этот метод и не возвращается к основному. Если Windows NT Challenge/Response не поддерживается, браузер использует Basic.

Когда ваш браузер устанавливает соединение с веб-сайтом, используя обычную или NTLM-проверку подлинности, он не переключается на анонимную аутентификацию в течение оставшейся части сеанса с сервером. Если вы попытаетесь подключиться к веб-странице, помеченной как анонимная, только после аутентификации, вам будет отказано.(Это может быть, а может и не быть верным для Netscape).
Когда Internet Explorer установил соединение с сервером, используя обычную проверку подлинности или проверку подлинности NTLM, он передает учетные данные для каждого нового запроса в течение всего сеанса.

Методы аутентификации, доступные для Windows 2000 и более поздних версий

Поддерживаемые браузеры: любые
Ограничения: нет
Требуются права пользователя: учетная запись анонимного пользователя, определенная на сервере, должна иметь разрешения на локальный вход.
Тип шифрования: нет

Поддерживаемые браузеры: любые
Ограничения: небезопасно. Пароли легко расшифровываются.
Требуются права пользователя: учетная запись пользователя должна иметь права локального входа в систему.
Тип шифрования: кодировка Base 64 (не настоящее шифрование)

Дайджест — сервер запрашивает у пользователя вход в систему, а также отправляет NONCE, используемый для шифрования пароля. Браузер использует NONCE для шифрования пароля и отправляет его на сервер. Затем сервер шифрует собственную копию пароля пользователя и сравнивает их. Если они совпадают и у пользователя есть разрешения, доступ предоставляется.

Поддерживаемые браузеры: Internet Explorer 5 и более поздние версии.
Ограничения. Не такой безопасный, как встроенный. Требуется, чтобы сервер имел доступ к серверу Active Directory, настроенному для дайджест-аутентификации.
Требуются права пользователя: в паролях должно быть указано «Сохранить пароль как зашифрованный открытый текст».
Тип шифрования: на основе NONCE, отправленного сервером.

Встроенная Windows (разделена на две подкатегории)

Kerberos — сервер запрашивает у пользователя вход в систему. Если браузер поддерживает Kerberos, происходит следующее:

IIS запрашивает аутентификацию.
Если клиент не вошел в домен, в Internet Explorer появится диалоговое окно с запросом учетных данных, а затем он свяжется с KDC, чтобы запросить и получить билет на предоставление билетов. Затем он отправляет билет на предоставление билетов вместе с информацией о сервере IIS в KDC.
Если клиент IE уже успешно вошел в домен и получил билет на получение билета, он отправляет этот билет вместе с информацией о сервере IIS в KDC.
KDC выдает клиенту ресурсный билет.
Клиент передает этот билет серверу IIS.

Kerberos использует билеты, сгенерированные на сервере предоставления билетов (KDC), для аутентификации. Он отправляет этот билет на сервер IIS. Браузер НЕ отправляет пароль пользователя на сервер.

Поддерживаемые браузеры: Internet Explorer версии 5.0 и выше
Ограничения: сервер должен иметь доступ к серверу Active Directory. И сервер, и клиент должны иметь доверенное соединение с KDC.
Требуются права пользователя: учетная запись анонимного пользователя, определенная на сервере, должна иметь разрешения на локальный вход.
Тип шифрования: зашифрованный билет.

Запрос/ответ Windows NT. Сервер запрашивает у пользователя вход в систему. Если браузер поддерживает Windows NT Challenge/Response, он автоматически отправляет учетные данные пользователя, если пользователь вошел в систему. Если домен, в котором находится пользователь, отличается от домена сервера или если пользователь не вошел в систему, в Internet Explorer появится диалоговое окно с запросом учетных данных для отправки. Windows NT Challenge/Response использует алгоритм для создания хэша на основе учетных данных пользователя и компьютера, который использует пользователь. Затем он отправляет этот хэш на сервер. Браузер не отправляет пароль пользователя на сервер.

Поддерживаемые браузеры: Internet Explorer версии 3.01 и выше.
Ограничения: требуется двухточечное соединение. Как правило, цепь закрывается после сообщения об ошибке «401 неавторизованный»; однако при согласовании последовательности проверки подлинности Windows NT Challenge/Response (которая требует нескольких круговых обходов) сервер сохраняет цепь открытой на протяжении всей последовательности после того, как клиент указал, что он будет использовать Windows NT Challenge/Response. Прокси-серверы CERN и некоторые другие интернет-устройства не позволяют этому работать.Кроме того, вызов/ответ Windows NT не поддерживает олицетворение с двойным переходом (это означает, что после передачи на сервер IIS те же учетные данные не могут быть переданы на внутренний сервер для проверки подлинности, например, когда IIS использует вызов/ответ Windows NT). , он не сможет аутентифицировать пользователя в базе данных SQL Server на другом компьютере с помощью встроенной безопасности SQL).
Требуются права пользователя: учетная запись пользователя, обращающаяся к серверу, должна иметь разрешение «Доступ к этому компьютеру из сети».
Тип шифрования: хэш-алгоритм NTLM, который также не закодирован.

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

Если интегрированный с Windows является единственным поддерживаемым методом (или если анонимный не работает), браузер должен поддерживать этот метод для связи с сервером. Если это не удается, сервер не пытается использовать другие методы.
Если единственным поддерживаемым методом является базовый (или если анонимный не работает), то в диалоговом окне появляется диалоговое окно для получения учетных данных, а затем передача их на сервер. Он пытается отправить учетные данные до трех раз. Если все это не удается, браузер не подключается к серверу.
Если поддерживаются как базовый, так и встроенный в Windows, браузер определяет, какой метод используется. Если браузер поддерживает Kerberos или Windows NT Challenge/Response, он использует этот метод. Он не возвращается к базовому. Если Windows NT Challenge/Response и Kerberos не поддерживаются, браузер использует Basic, Digest или Fortezza, если он их поддерживает. Порядок приоритета здесь: Basic, Digest, а затем Fortezza.

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

Ссылки

Дополнительные сведения о настройке проверки подлинности веб-сайта IIS в Windows Server 2003 см. в разделе Настройка проверки подлинности веб-сайта IIS в Windows Server 2003.

Я выступил с докладом на тему "Обработка секретов аутентификации в браузере" на конференции Fluent 2017 в Сан-Хосе (см. слайды выше). В качестве дополнения к докладу я подумал, что было бы неплохо записать основные понятия и здесь, в блоге, для тех, кто не был на моем докладе или был, но хочет изучить тему более подробно. времени, чем те 40 минут, которые у меня были на презентацию.

Интернет не имеет состояния

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

Обычные формы аутентификации

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

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

Пароли, токены, файлы cookie. В чем разница?

Я уже упоминал о трех наиболее распространенных формах аутентификации в веб-приложениях, но как они соотносятся друг с другом?

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

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

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

Сеансы пользователей

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

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

Другой стиль пользовательского сеанса – это когда клиенту отправляется реальный сеанс пользователя со всеми его данными, а не просто ссылка на хранилище на стороне сервера. Это имеет то преимущество, что серверу не нужно управлять хранилищем для пользовательских сеансов. Чтобы гарантировать, что пользовательские сеансы не будут подделаны, пока они находятся во владении клиента, они защищены криптографической подписью, которую знает только сервер. Если клиент попытается изменить содержимое сеанса, то подпись больше не будет соответствовать данным, и сервер отклонит ее. Спецификация веб-токенов JSON является распространенным решением для реализации подписанных пользовательских сеансов.

Базовая защита секретов

Покончив с основами, давайте теперь рассмотрим меры, которые необходимо предпринять для защиты учетных данных пользователя в веб-приложении.

Атаки на веб-браузер

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

Есть два очень распространенных вектора атак, характерных для веб-браузеров, которые происходят из-за того, что приложения не могут защитить секреты в браузере:

Межсайтовый скриптинг или XSS
Подделка межсайтовых запросов или CSRF (иногда XSRF)

Помимо похожих загадочных названий, эти двое на самом деле совершенно разные и имеют разные стратегии защиты.

Атаки с использованием межсайтовых сценариев

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

В выступлении на Fluent я использовал картинку из пародии на пришельцев «Космические шары», чтобы изобразить этот тип уязвимости в юмористической форме, поскольку код JavaScript, внедренный злоумышленником, становится паразитом, который живет и питается вашим собственным приложением.< /p>

Как защититься от XSS-атак

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

Теперь, если ваше приложение имеет социальные функции, самое главное, что вы должны сделать для предотвращения XSS-атак, — это регулярно проверять свой код и проверять, что все данные, вводимые пользователями, очищены, в частности, в отношении комментариев или других пользователей социального контента. способствовать. Но поскольку мы люди и часто склонны совершать ошибки, полагаться только на аудит недостаточно.К счастью, есть ряд мер, которые вы можете предпринять, чтобы защитить себя от этого неприятного типа атак:

Практика, которую я, к сожалению, видел слишком много раз, включает использование сторонних токенов доступа или учетных данных в клиентских приложениях. Например, сюда входят токены OAuth от Facebook, Google и т. д., а также ключи доступа из учетных записей AWS. Проблема с этой практикой заключается в том, что если злоумышленнику удастся успешно внедрить код JavaScript в ваше приложение, то абсолютно невозможно защитить эти секреты, существующие в контексте клиентского приложения, от кражи. Так что это ужасная идея, никогда не позволяйте приложению, предназначенному для работы в браузере, обрабатывать секреты третьих лиц. Эти секреты должны безопасно храниться на сервере, и если клиентское приложение должно их использовать, оно должно использовать ваш сервер приложений в качестве посредника.

Атаки с подделкой межсайтовых запросов

Атаки CSRF — это удаленные атаки, в том смысле, что вам не нужно, чтобы ваше приложение проникло в код злоумышленника, чтобы быть уязвимым, как в случае с XSS.

В своем выступлении я использовал картинку из фильма Face/Off, чтобы проиллюстрировать этот тип атаки. На картинке вы можете увидеть Джона Траволту, который является хорошим парнем. Он сможет пойти куда угодно, куда позволено Джону Траволте, потому что у него лицо Джона Траволты. Но на самом деле это плохой парень, которого играет Николас Кейдж, пока ему не сделают пересадку лица. Если оставить в стороне глупость идеи фильма, с помощью CSRF «плохие» запросы, которые отправляет злоумышленник, маскируются под «хорошие» запросы с помощью политики браузера в отношении файлов cookie.

Как защититься от CSRF-атак

Методы защиты от CSRF полностью отличаются, а иногда даже противоречат тем, которые мы используем для XSS. Базовый уровень защиты для этого вектора атаки заключается в том, чтобы ваше приложение проверяло заголовки Origin и/или Referer, отправляемые веб-браузерами, которые указывают, какой исходный сайт делает запрос. Эти заголовки не могут быть установлены с помощью JavaScript, поэтому злоумышленник не сможет их подделать. К сожалению, только современные браузеры реализуют эти заголовки, так что это не дает вам надежной защиты от этого типа атак.

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

Что делать со скомпрометированными учетными данными

После этого мучительно долгого обсуждения всех векторов атак и того, как их можно смягчить, у меня есть очень плохие новости: ваше приложение по-прежнему уязвимо для атак.

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

По сути, мой последний совет сводится к плану действий на случай возникновения уязвимости. Что значит иметь план? Я могу перечислить следующие пункты для вашего рассмотрения:

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

Заключение

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

Здравствуйте! Спасибо, что посетили мой блог! Если вам понравилась эта статья, поддержите мою работу над этим блогом на Patreon!

Поддерживаемые схемы аутентификации

Chrome поддерживает четыре схемы аутентификации: Basic, Digest, NTLM и Negotiate. Basic, Digest и NTLM по умолчанию поддерживаются на всех платформах. Negotiate по умолчанию поддерживается на всех платформах, кроме Chrome OS.

Схемы Basic и Digest указаны в RFC 2617. NTLM — это собственный протокол Microsoft. Схема Negotiate (или SPNEGO) указана в RFC 4559 и может использоваться для согласования нескольких схем аутентификации, но обычно по умолчанию используется либо Kerberos, либо NTLM.

Список поддерживаемых схем аутентификации может быть переопределен с помощью политики AuthSchemes. Подробнее об использовании административных политик см. на этой странице.

Выбор схемы аутентификации

Схема Basic имеет наименьшую оценку, поскольку она отправляет имя пользователя/пароль в незашифрованном виде на сервер или прокси-сервер.

Поэтому мы выбираем наиболее безопасную схему и игнорируем предпочтения сервера или прокси, указанные порядком, в котором схемы перечислены в заголовках ответов WWW-Authenticate или Proxy-Authenticate. Это может быть источником проблем с совместимостью, поскольку документация MSDN гласит, что «WinInet выбирает первый распознанный метод». Примечание. В IE7 или более поздних версиях WinInet выбирает первый распознанный небазовый метод.

Встроенная аутентификация

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

Из-за потенциальных атак встроенная аутентификация включается только тогда, когда Chrome получает запрос аутентификации от прокси-сервера или когда он получает запрос от сервера, который находится в разрешенном списке.

Этот список передается в Chrome с помощью списка URL-адресов, разделенных запятыми, в Chrome с помощью параметра политики AuthServerWhitelist. Например, если параметр политики AuthServerWhitelist был следующим:

В ==только для Windows==, если параметр AuthServerWhitelist не указан, разрешенный список состоит из тех серверов, которые разрешены диспетчером безопасности зон Windows (запрошен для URLACTION_CREDENTIALS_USE). По умолчанию сюда входят серверы в зонах безопасности «Локальный компьютер» или «Локальная интрасеть». Например, когда хост в URL-адресе включает "." символ, по умолчанию он находится за пределами зоны безопасности локальной интрасети). Это поведение соответствует Internet Explorer и другим компонентам Windows.

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

Начиная с Chrome 81, встроенная аутентификация по умолчанию отключена для профилей без записи (инкогнито/гость), и пользователю нужно будет ввести имя пользователя и пароль.

Генерация имени участника-службы Kerberos

Когда сервер или прокси-сервер предъявляет Chrome запрос на согласование, Chrome пытается сгенерировать Kerberos SPN (имя субъекта-службы) на основе хоста и порта исходного URI. К сожалению, сервер не указывает, какое имя участника-службы должно быть в рамках проверки подлинности, поэтому Chrome (и другие браузеры) должен угадать, каким оно должно быть, основываясь на стандартных соглашениях.

Создание SPN можно настроить с помощью параметров политики:

определяет, используется ли исходное имя хоста в URL-адресе, а не каноническое имя. Если параметр не задан или установлен в значение false, Chrome использует каноническое имя. определяет, добавляется ли порт к имени участника-службы, если это нестандартный (не 80 или 443) порт. Если установлено значение true, порт добавляется. В противном случае (или если он не установлен) порт не используется.

Например, предположим, что интрасеть имеет такую конфигурацию DNS, как

Делегирование учетных данных Kerberos (пересылаемые билеты)

Некоторые службы требуют делегирования удостоверения пользователя (например, сервер IIS, обращающийся к базе данных MSSQL). По умолчанию Chrome этого не позволяет. Вы можете использовать политику AuthNegotiateDelegateWhitelist, чтобы включить ее для серверов.

Делегирование не работает для проверки подлинности прокси.

Договориться о внешних библиотеках

В Windows Negotiate реализован с использованием библиотек SSPI и зависит от кода в secur32.dll.

На Android Negotiate реализуется с помощью внешнего приложения аутентификации, предоставленного сторонними поставщиками. Подробности приведены в статье Создание аутентификатора SPNEGO для Chrome на Android. Политика AuthAndroidNegotiateAccountType используется, чтобы сообщить Chrome тип учетной записи Android, предоставленный приложением, что позволяет ему найти приложение.

На других платформах Negotiate реализован с использованием системных библиотек GSSAPI. При первом появлении проблемы Negotiate Chrome пытается открыть одну из нескольких возможных общих библиотек. Если не удается найти подходящую библиотеку, Chrome запоминает сеанс, и все вызовы Negotiate игнорируются для вызовов с более низким приоритетом.

Политику GSAPILibraryName можно использовать для указания пути к библиотеке GSSAPI, которую должен использовать Chrome.

В противном случае Chrome пытается выполнить dlopen/dlsym для каждого из следующих фиксированных имен в указанном порядке:

Chrome OS следует поведению Linux, но не имеет системной библиотеки gssapi, поэтому все вызовы Negotiate игнорируются.

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

Опубликовано 25 августа 2008 г.

Они были стандартными для веб-браузеров с 1558 года нашей эры, когда легендарный Герцог Логина впервые изобрел идею входа в систему. С уважением!

Большинство веб-разработчиков, которые хотят выполнять программную аутентификацию (т. е. проверять учетные данные с помощью аутентификации с помощью форм или напрямую с базой данных), не используют это встроенное приглашение для входа в браузер по двум причинам:

Непонятно, как заставить его работать с программной аутентификацией
Считается небезопасным (по какой-то причине)

Итак, как на самом деле работает стандартное приглашение для входа? Что заставляет его появляться и какие данные он отправляет из браузера на сервер?

Допустим, вы хотите совместить проверку подлинности с помощью форм с запросом на вход в браузере. Начните с настройки проверки подлинности с помощью форм, т. е. поместите ее в свой файл web.config:

Обратите внимание, что e9fe51… — это хеш SHA1 «mysecret», поэтому в этой конфигурации используется одно жестко заданное имя пользователя «admin» с паролем «mysecret». В более реалистичном приложении у вас, вероятно, не было бы их в файле web.config, и вместо этого вы настроили бы поставщика членства для хранения учетных данных в базе данных. Но это не меняет остальной части этого примера.

Теперь, если вы украсили какой-либо контроллер или метод действия с помощью [Authorize], когда пользователь посещает этот контроллер или действие, он будет перенаправлен на ~/Account/Login. Чтобы обработать этот запрос, создайте новый класс контроллера с именем AccountController следующим образом. Вы можете заменить реализацию AccountController по умолчанию, если она у вас есть.

Вот оно! Теперь, когда посетитель перейдет к чему-либо, защищенному с помощью [Авторизация], он получит встроенное в браузер приглашение для входа в систему, такое как показано ниже. Если посетитель вводит действительные учетные данные (например, admin/mysecret), ему будет предоставлен файл cookie проверки подлинности с помощью форм, и он будет перенаправлен обратно к запрошенному методу действия.

Обратите внимание, что на этом снимке экрана IE выдает предупреждение о «основной аутентификации без безопасного соединения». Мы поговорим о безопасных соединениях (SSL) чуть позже.

Какой простой способ получить красивый интерфейс входа в систему.

Это безопасно?

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

Заключение

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