Аутентификация пользователей: Аутентификация и авторизация в микросервисных приложениях / Блог компании DataArt / Хабр

Содержание

Идентификация, аутентификация и авторизация

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

Содержание статьи:

Определения

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

Механизмы идентификации, аутентификации и авторизации

Находясь на сайте банка, пользователь решает зайти в личный кабинет, чтобы сделать денежный перевод. На странице личного кабинета система вначале просит ввести идентификатор. Это может быть логин, имя и фамилия, адрес электронной почты или номер мобильного телефона.
Какой конкретно вид данных необходимо ввести – зависит от ресурса. Данные, которые указывались при регистрации, необходимо ввести для получения доступа. Если при регистрации указывалось несколько типов данных – и логин, и адрес электронной почты, и номер мобильного, то система сама подскажет что ей конкретно нужно.
Ввод этих данных необходим для идентификации человека за монитором как пользователя конкретно этого банка. Если пользователь в качестве идентификатора ввел «Александр Петров», и система нашла в своей базе запись о пользователе с таким именем, то идентификация завершилась. После идентификации следует процесс аутентификации, в котором пользователю нужно доказать, что он является человеком, который регистрировался под именем Александр Петров. Для доказательства необходимо наличие одного из типов аутентификационных данных:
  • Нечто, присущее только пользователю. Биометрические данные: сканеры лица, отпечатки пальцев или сетчатки глаза.
  • Нечто, известное только пользователю. Сюда относятся pin-коды, пароли, графические ключи, секретные слова.
  • Нечто, имеющееся у пользователя. В данном качестве может выступать токен, то есть компактное устройство, предназначенное для обеспечения информационной безопасности пользователя, также используется для идентификации владельца. Самые простые токены не требуют физического подключения к компьютеру – у них имеется дисплей, где отображается число, которое пользователь вводит в систему для осуществления входа; более сложные подключаются к компьютерам посредством USB и Bluetooth-интерфейсов.
Самый распространенный тип аутентификационных данных – это пароль. Именно поэтому так важно создавать и правильно хранить свои пароли. Подробнее об этом можно прочитать в статьях «Создание надежных паролей» и «Как правильно выбирать и хранить пароли». После ввода пользователем пароля система проверяет: соответствует ли условный пароль «Q45fp[email protected]» пользователю с именем Александр Петров. Таким образом происходит аутентификация. Если все верно, и пара логин-пароль верны, то система предоставит пользователю доступ к его ресурсам и совершение банковских операций, то есть произойдет
авторизация
. Описанные процессы всегда происходят только в таком порядке: идентификация, аутентификация, авторизация. Вся цепочка потеряет смысл, если, например, сайт сначала предоставит доступ к денежным средствам пользователя, а потом будет уточнять, он ли это на самом деле. Процессы идентификации, аутентификации и авторизации характерны не только для онлайн-банкинга, но и для электронной почты, социальных сетей и других ресурсов. В реальной жизни мы также сталкиваемся идентификацией, аутентификацией и авторизацией. Примером может служить проверка документов сотрудником полиции. Вы представились как Александр Петров, и сотрудник полиции идентифицировал Вас как Александра Петрова. Для аутентификации необходим паспорт, в котором видно, что Александр Петров выглядит так же, как и вы. Авторизацией в данном случае будет то, что сотрудник отпустит вас и пожелает счастливого пути, т.е. предоставит право свободного перемещения. Процессы идентификации, аутентификации и авторизации есть во многих сферах. Даже в простейших детских сказках. Сказка «Волк и семеро козлят» является идеальным примером для демонстрации. Здесь козлята выступают в роли системы безопасности, идентифицируя каждого, кто подходит к двери. В качестве данных для аутентификации выступает биометрия – тонкий голосок мамы-козы. И если в первый раз волк не смог пройти аутентификацию (его выдал грубый голос), то со второй попытки (после того как ему перековали горло, и он запел тонким голоском) он аутентифицировался как мама-коза и козлята «авторизовали» его в свою избу. Несмотря на то, что сказка закончилась благополучно, доступ к козлятам был получен неправомерно. Волку удалось обмануть процессы идентификации и аутентификации и тем самым пройти авторизацию. Если в старой детской сказке это оказалось возможным, то что говорить о современных злоумышленниках. Чтобы защитить свои денежные средства и персональные данные и козлят от волка от злоумышленника необходимо использовать более сложные способы аутентификации.

Многофакторная аутентификация

Многофакторная аутентификация представляет собой метод, при котором пользователю для доступа к учетной записи или подтверждения операции с денежными средствами необходимо двумя различными факторами доказать, что именно он владелец учетной записи или что именно он осуществляет вход. Среди видов многофакторной аутентификации наиболее распространена двухфакторная аутентификация (2FA — 2-factor authentication) – метод, при котором пользователю для получения доступа необходимо предоставить два разных типа аутентификационных данных, например, что-то известное только пользователю (пароль) и что-то присущее только пользователю (отпечаток пальца). Доступ к ресурсам через ввод логина и пароля, является однофакторной аутентификацией, поскольку для входа используется только один тип аутентификационных данных — известный пользователю пароль.

Однофакторная двухэтапная аутентификация

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

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

Рекомендации

  1. Используйте уникальные, надежные пароли для разных учетных записей.
  2. Настройте двухэтапную однофакторную или многофакторную аутентификацию на всех ресурсах, где это возможно.

✅ Аутентификация: Определение, Методы, Виды

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

Она не тождественна идентификации и авторизации. Эти три термина являются элементами защиты информации. Первая стадия — идентификация. На ней происходит распознавание информации о пользователе, например, логин и пароль. Вторая стадия — аутентификация. Это процесс проверки информации о пользователе. Третья стадия — авторизация. Здесь происходит проверка прав пользователя и определяется возможность доступа.

Стадии доступа

Зачем нужна аутентификация

Аутентификация нужна для доступа к:

  1. Соцсетям
  2. Электронной почте
  3. Интернет-магазинам
  4. Форумам
  5. Интернет-банкингу
  6. Платежным системам

Элементы аутентификации

  1. Субъект — пользователь
  2. Характеристика субъекта — информация, предоставляемая пользователем для проверки подлинности.
  3. Владелец системы аутентификации — владелец ресурса.
  4. Механизм аутентификации — принцип проверки
  5. Механизм авторизации — управление доступом

Методы аутентификации

  1. Парольные
  2. Комбинированные
  3. Биометрические
  4. Информация о пользователе
  5. Пользовательские данные

Парольные

Самый распространенный метод. Аутентификация может проходить по одноразовым и многоразовым паролям. Многоразовый пароль задает пользователь, а система хранит его в базе данных. Он является одинаковым для каждой сессии. К ним относятся PIN-коды, слова, цифры, графические ключи. Одноразовые пароли — разные для каждой сессии. Это может быть SMS с кодом. 

Комбинированные

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

Биометрические

Это самый дорогостоящий метод аутентификации. Он предотвращает утечку или кражу персональной информации. Проверка проходит по физиологическим характеристикам пользователя, например, по отпечатку пальца, сетчатке глаза, тембру голоса и даже ДНК.

Информация о пользователе

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

Пользовательские данные

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

Классификация видов аутентификации

В зависимости от количества используемых методов

  • Однофакторная. Используется только один метод.
  • Многофакторная. Используется несколько методов.

В зависимости от политики безопасности систем и уровня доверия

  • Односторонняя. Пользователь доказывает право доступа к ресурсу его владельцу.
  • Взаимная. Проверяется подлинность прав доступа и пользователя и владельца сайта. Для этого используют криптографические способы.

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

Типы протоколов обусловлены тем, где происходит аутентификация — на PC или в сети.

Аутентификация на PC

  • Login
  • PAP (Password Authentication Protocol) — логин и пароль
  • Карта доступа — USB и сертификаты
  • Биометрические данные

Аутентификация в сети

  • Cookies. Используются для отслеживания сеанса, сохранения предпочтений и сбора статистики. Степень защиты невысокая, однако привязка к IP-адресу решает эту проблему.
  • Kerberos. Протокол взаимной аутентификации с помощью криптографического ключа.
  • SAML (Security Assertion Markup Language) Язык разметки, который позволяет сторонам обмениваться данными аутентификации.
  • SNMP (Simple Network Management Protocol) Протокол, который контролирует подключенные к сети устройства.
  • Сертификаты X.509 Сертификаты с открытым ключом.
  • OpenID Connect. Используется для создания единой учетной записи для аутентификации на разных ресурсах.

Ресурсы

  1. В этой статье детально рассмотрены элементы, факторы и способы аутентификации.
  2. В этой статье объясняют, для доступа на какие сервисы нужна аутентификация и рассматривают классификацию её методов.

Обновлено: 2020-06-25

Оцените, насколько полезна статья "Аутентификация"

Оценка: 5 / 5 (12)

Обзор способов и протоколов аутентификации в веб-приложениях

Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

  • Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
  • Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
  • Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

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

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

Аутентификация по паролю

Этот метод основывается на том, что пользователь должен предоставить username и password для успешной идентификации и аутентификации в системе. Пара username/password задается пользователем при его регистрации в системе, при этом в качестве username может выступать адрес электронной почты пользователя.

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

HTTP authentication

Этот протокол, описанный в стандартах HTTP 1.0/1.1, существует очень давно и до сих пор активно применяется в корпоративной среде. Применительно к веб-сайтам работает следующим образом:
  1. Сервер, при обращении неавторизованного клиента к защищенному ресурсу, отсылает HTTP статус “401 Unauthorized” и добавляет заголовок “WWW-Authenticate” с указанием схемы и параметров аутентификации.
  2. Браузер, при получении такого ответа, автоматически показывает диалог ввода username и password. Пользователь вводит детали своей учетной записи.
  3. Во всех последующих запросах к этому веб-сайту браузер автоматически добавляет HTTP заголовок “Authorization”, в котором передаются данные пользователя для аутентификации сервером.
  4. Сервер аутентифицирует пользователя по данным из этого заголовка. Решение о предоставлении доступа (авторизация) производится отдельно на основании роли пользователя, ACL или других данных учетной записи.

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

  1. Basic — наиболее простая схема, при которой username и password пользователя передаются в заголовке Authorization в незашифрованном виде (base64-encoded). Однако при использовании HTTPS (HTTP over SSL) протокола, является относительно безопасной.

    Пример HTTP аутентификации с использованием Basic схемы.
  2. Digest — challenge-response-схема, при которой сервер посылает уникальное значение nonce, а браузер передает MD5 хэш пароля пользователя, вычисленный с использованием указанного nonce. Более безопасная альтернативв Basic схемы при незащищенных соединениях, но подвержена man-in-the-middle attacks (с заменой схемы на basic). Кроме того, использование этой схемы не позволяет применить современные хэш-функции для хранения паролей пользователей на сервере.
  3. NTLM (известная как Windows authentication) — также основана на challenge-response подходе, при котором пароль не передается в чистом виде. Эта схема не является стандартом HTTP, но поддерживается большинством браузеров и веб-серверов. Преимущественно используется для аутентификации пользователей Windows Active Directory в веб-приложениях. Уязвима к pass-the-hash-атакам.
  4. Negotiate — еще одна схема из семейства Windows authentication, которая позволяет клиенту выбрать между NTLM и Kerberos аутентификацией. Kerberos — более безопасный протокол, основанный на принципе Single Sign-On. Однако он может функционировать, только если и клиент, и сервер находятся в зоне intranet и являются частью домена Windows.

Стоит отметить, что при использовании HTTP-аутентификации у пользователя нет стандартной возможности выйти из веб-приложения, кроме как закрыть все окна браузера.
Forms authentication

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

Работает это по следующему принципу: в веб-приложение включается HTML-форма, в которую пользователь должен ввести свои username/password и отправить их на сервер через HTTP POST для аутентификации. В случае успеха веб-приложение создает session token, который обычно помещается в browser cookies. При последующих веб-запросах session token автоматически передается на сервер и позволяет приложению получить информацию о текущем пользователе для авторизации запроса.


Пример forms authentication.

Приложение может создать session token двумя способами:

  1. Как идентификатор аутентифицированной сессии пользователя, которая хранится в памяти сервера или в базе данных. Сессия должна содержать всю необходимую информацию о пользователе для возможности авторизации его запросов.
  2. Как зашифрованный и/или подписанный объект, содержащий данные о пользователе, а также период действия. Этот подход позволяет реализовать stateless-архитектуру сервера, однако требует механизма обновления сессионного токена по истечении срока действия. Несколько стандартных форматов таких токенов рассматриваются в секции «Аутентификация по токенам».

Необходимо понимать, что перехват session token зачастую дает аналогичный уровень доступа, что и знание username/password. Поэтому все коммуникации между клиентом и сервером в случае forms authentication должны производиться только по защищенному соединению HTTPS.
Другие протоколы аутентификации по паролю

Два протокола, описанных выше, успешно используются для аутентификации пользователей на веб-сайтах. Но при разработке клиент-серверных приложений с использованием веб-сервисов (например, iOS или Android), наряду с HTTP аутентификацией, часто применяются нестандартные протоколы, в которых данные для аутентификации передаются в других частях запроса.

Существует всего несколько мест, где можно передать username и password в HTTP запросах:

  1. URL query — считается небезопасным вариантом, т. к. строки URL могут запоминаться браузерами, прокси и веб-серверами.
  2. Request body — безопасный вариант, но он применим только для запросов, содержащих тело сообщения (такие как POST, PUT, PATCH).
  3. HTTP header —оптимальный вариант, при этом могут использоваться и стандартный заголовок Authorization (например, с Basic-схемой), и другие произвольные заголовки.
Распространенные уязвимости и ошибки реализации
Аутентификации по паролю считается не очень надежным способом, так как пароль часто можно подобрать, а пользователи склонны использовать простые и одинаковые пароли в разных системах, либо записывать их на клочках бумаги. Если злоумышленник смог выяснить пароль, то пользователь зачастую об этом не узнает. Кроме того, разработчики приложений могут допустить ряд концептуальных ошибок, упрощающих взлом учетных записей.

Ниже представлен список наиболее часто встречающихся уязвимостей в случае использования аутентификации по паролю:

  • Веб-приложение позволяет пользователям создавать простые пароли.
  • Веб-приложение не защищено от возможности перебора паролей (brute-force attacks).
  • Веб-приложение само генерирует и распространяет пароли пользователям, однако не требует смены пароля после первого входа (т.е. текущий пароль где-то записан).
  • Веб-приложение допускает передачу паролей по незащищенному HTTP-соединению, либо в строке URL.
  • Веб-приложение не использует безопасные хэш-функции для хранения паролей пользователей.
  • Веб-приложение не предоставляет пользователям возможность изменения пароля либо не нотифицирует пользователей об изменении их паролей.
  • Веб-приложение использует уязвимую функцию восстановления пароля, которую можно использовать для получения несанкционированного доступа к другим учетным записям.
  • Веб-приложение не требует повторной аутентификации пользователя для важных действий: смена пароля, изменения адреса доставки товаров и т. п.
  • Веб-приложение создает session tokens таким образом, что они могут быть подобраны или предсказаны для других пользователей.
  • Веб-приложение допускает передачу session tokens по незащищенному HTTP-соединению, либо в строке URL.
  • Веб-приложение уязвимо для session fixation-атак (т. е. не заменяет session token при переходе анонимной сессии пользователя в аутентифицированную).
  • Веб-приложение не устанавливает флаги HttpOnly и Secure для browser cookies, содержащих session tokens.
  • Веб-приложение не уничтожает сессии пользователя после короткого периода неактивности либо не предоставляет функцию выхода из аутентифицированной сессии.
Аутентификация по сертификатам

Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный certificate authority (CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.


Использование сертификата для аутентификации.

Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:

  1. Сертификат должен быть подписан доверенным certification authority (проверка цепочки сертификатов).
  2. Сертификат должен быть действительным на текущую дату (проверка срока действия).
  3. Сертификат не должен быть отозван соответствующим CA (проверка списков исключения).


Пример X.509 сертификата.

После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).

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

Аутентификация по одноразовым паролям

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации two-factor authentication (2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

Другой популярный сценарий использования одноразовых паролей — дополнительная аутентификация пользователя во время выполнения важных действий: перевод денег, изменение настроек и т. п.

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

  1. Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
  2. Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
  3. Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.


Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

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

Аутентификация по ключам доступа

Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (access key, API key) — длинные уникальные строки, содержащие произвольный набор символов, по сути заменяющие собой комбинацию username/password.

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

Хороший пример применения аутентификации по ключу — облако Amazon Web Services. Предположим, у пользователя есть веб-приложение, позволяющее загружать и просматривать фотографии, и он хочет использовать сервис Amazon S3 для хранения файлов. В таком случае, пользователь через консоль AWS может создать ключ, имеющий ограниченный доступ к облаку: только чтение/запись его файлов в Amazon S3. Этот ключ в результате можно применить для аутентификации веб-приложения в облаке AWS.


Пример применения аутентификации по ключу.

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

С технической точки зрения, здесь не существует единого протокола: ключи могут передаваться в разных частях HTTP-запроса: URL query, request body или HTTP header. Как и в случае аутентификации по паролю, наиболее оптимальный вариант — использование HTTP header. В некоторых случаях используют HTTP-схему Bearer для передачи токена в заголовке (Authorization: Bearer [token]). Чтобы избежать перехвата ключей, соединение с сервером должно быть обязательно защищено протоколом SSL/TLS.


Пример аутентификации по ключу доступа, переданного в HTTP заголовке.

Кроме того, существуют более сложные схемы аутентификации по ключам для незащищенных соединений. В этом случае, ключ обычно состоит их двух частей: публичной и секретной. Публичная часть используется для идентификации клиента, а секретная часть позволяет сгенерировать подпись. Например, по аналогии с digest authentication схемой, сервер может послать клиенту уникальное значение nonce или timestamp, а клиент — возвратить хэш или HMAC этого значения, вычисленный с использованием секретной части ключа. Это позволяет избежать передачи всего ключа в оригинальном виде и защищает от replay attacks.

Аутентификация по токенам

Такой способ аутентификации чаще всего применяется при построении распределенных систем Single Sign-On (SSO), где одно приложение (service provider или relying party) делегирует функцию аутентификации пользователей другому приложению (identity provider или authentication service). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение доверяет функцию аутентификации пользователей социальным сетям.

Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе в виде токена, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.
На общем уровне, весь процесс выглядит следующим образом:

  1. Клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.).
  2. Клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту.
  3. Клиент аутентифицируется в SP-приложении при помощи этого токена.


Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.

Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем. В этом случае аутентификация достигается посредством автоматического перенаправления браузера между веб-приложениями identity provider и service provider.


Пример аутентификации «пассивного» клиента посредством перенаправления запросов.

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.

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

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

  1. Токен был выдан доверенным identity provider приложением (проверка поля issuer).
  2. Токен предназначается текущему SP-приложению (проверка поля audience).
  3. Срок действия токена еще не истек (проверка поля expiration date).
  4. Токен подлинный и не был изменен (проверка подписи).

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

Форматы токенов

Существует несколько распространенных форматов токенов для веб-приложений:
  1. Simple Web Token (SWT) — наиболее простой формат, представляющий собой набор произвольных пар имя/значение в формате кодирования HTML form. Стандарт определяет несколько зарезервированных имен: Issuer, Audience, ExpiresOn и HMACSHA256. Токен подписывается с помощью симметричного ключа, таким образом оба IP- и SP-приложения должны иметь этот ключ для возможности создания/проверки токена.

    Пример SWT токена (после декодирования).

    Issuer=http://auth.myservice.com&
    Audience=http://myservice.com&
    ExpiresOn=1435937883&
    UserName=John Smith&
    UserRole=Admin&
    HMACSHA256=KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w

  2. JSON Web Token (JWT) — содержит три блока, разделенных точками: заголовок, набор полей (claims) и подпись. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Набор полей содержит произвольные пары имя/значения, притом стандарт JWT определяет несколько зарезервированных имен (iss, aud, exp и другие). Подпись может генерироваться при помощи и симметричных алгоритмов шифрования, и асимметричных. Кроме того, существует отдельный стандарт, отписывающий формат зашифрованного JWT-токена.

    Пример подписанного JWT токена (после декодирования 1 и 2 блоков).

    { «alg»: «HS256», «typ»: «JWT» }.
    { «iss»: «auth.myservice.com», «aud»: «myservice.com», «exp»: «1435937883», «userName»: «John Smith», «userRole»: «Admin» }.
    S9Zs/8/uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY
  3. Security Assertion Markup Language (SAML) — определяет токены (SAML assertions) в XML-формате, включающем информацию об эмитенте, о субъекте, необходимые условия для проверки токена, набор дополнительных утверждений (statements) о пользователе. Подпись SAML-токенов осуществляется при помощи ассиметричной криптографии. Кроме того, в отличие от предыдущих форматов, SAML-токены содержат механизм для подтверждения владения токеном, что позволяет предотвратить перехват токенов через man-in-the-middle-атаки при использовании незащищенных соединений.
Стандарт SAML

Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.

Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:

  1. Assertions — собственный формат SAML токенов в XML формате.
  2. Protocols — набор поддерживаемых сообщений между участниками, среди которых — запрос на создание нового токена, получение существующих токенов, выход из системы (logout), управление идентификаторами пользователей, и другие.
  3. Bindings — механизмы передачи сообщений через различные транспортные протоколы. Поддерживаются такие способы, как HTTP Redirect, HTTP POST, HTTP Artifact (ссылка на сообщения), SAML SOAP, SAML URI (адрес получения сообщения) и другие.
  4. Profiles — типичные сценарии использования стандарта, определяющие набор assertions, protocols и bindings необходимых для их реализации, что позволяет достичь лучшей совместимости. Web Browser SSO — один из примеров таких профилей.

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

Рассмотрим краткий пример использования SAML для сценария Single Sign-On. Пользователь хочет получить доступ на защищенный ресурс сервис-провайдера (шаг № 1 на диаграмме аутентификации пассивных клиентов). Т. к. пользователь не был аутентифицирован, SP отправляет его на сайт identity provider’а для создания токена (шаг № 2). Ниже приведен пример ответа SP, где последний использует SAML HTTP Redirect binding для отправки сообщения с запросом токена:

В случае такого запроса, identity provider аутентифицирует пользователя (шаги №3-4), после чего генерирует токен. Ниже приведен пример ответа IP с использованием HTTP POST binding (шаг № 5):

После того как браузер автоматически отправит эту форму на сайт service provider’а (шаг № 6), последний декодирует токен и аутентифицирует пользователя. По результатам успешной авторизации запроса пользователь получает доступ к запрошенному ресурсу (шаг № 7).

Стандарты WS-Trust и WS-Federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

  • Формат и способы обмена метаданными о сервисах.
  • Функцию единого выхода из всех систем (single sign-out).
  • Сервис атрибутов, предоставляющий дополнительную информацию о пользователе.
  • Сервис псевдонимов, позволяющий создавать альтернативные имена пользователей.
  • Поддержку пассивных клиентов (браузеров) посредством перенаправления.

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Стандарты OAuth и OpenID Connect

В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).

Первая версия стандарта разрабатывалась в 2007 – 2010 гг., а текущая версия 2.0 опубликована в 2012 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.

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

> Попросить пользователя указать данные своей учетной записи? — плохой вариант.
> Попросить пользователя создать ключ доступа? — возможно, но весьма сложно.

Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:

  1. Пользователь (resource owner) дает разрешение приложению (client) на доступ к определенному ресурсу в виде гранта. Что такое грант, рассмотрим чуть ниже.
  2. Приложение обращается к серверу авторизации и получает токен доступа к ресурсу в обмен на свой грант. В нашем примере сервер авторизации — Google. При вызове приложение дополнительно аутентифицируется при помощи ключа доступа, выданным ему при предварительной регистрации.
  3. Приложение использует этот токен для получения требуемых данных от сервера ресурсов (в нашем случае — сервис Gmail).


Взаимодействие компонентов в стандарте OAuth.

Стандарт описывает четыре вида грантов, которые определяют возможные сценарии применения:

  1. Authorization Code — этот грант пользователь может получить от сервера авторизации после успешной аутентификации и подтверждения согласия на предоставление доступа. Такой способ наиболее часто используется в веб-приложениях. Процесс получения гранта очень похож на механизм аутентификации пассивных клиентов в SAML и WS-Federation.
  2. Implicit — применяется, когда у приложения нет возможности безопасно получить токен от сервера авторизации (например, JavaScript-приложение в браузере). В этом случае грант представляет собой токен, полученный от сервера авторизации, а шаг № 2 исключается из сценария выше.
  3. Resource Owner Password Credentials — грант представляет собой пару username/password пользователя. Может применяться, если приложение является «интерфейсом» для сервера ресурсов (например, приложение — мобильный клиент для Gmail).
  4. Client Credentials — в этом случае нет никакого пользователя, а приложение получает доступ к своим ресурсам при помощи своих ключей доступа (исключается шаг № 1).

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

  1. Зачастую API сервера ресурсов включает операцию, предоставляющую информацию о самом пользователе (например, /me в Facebook API). Приложение может выполнять эту операцию каждый раз после получения токена для идентификации клиента. Такой метод иногда называют псевдо-аутентификацией.
  2. Использовать стандарт OpenID Connect, разработанный как слой учетных данных поверх OAuth (опубликован в 2014 г.). В соответствии с этим стандартом, сервер авторизации предоставляет дополнительный identity token на шаге № 2. Этот токен в формате JWT будет содержать набор определенных полей (claims) с информацией о пользователе.

Стоит заметить, что OpenID Connect, заменивший предыдущие версии стандарта OpenID 1.0 и 2.0, также содержит набор необязательных дополнений для поиска серверов авторизации, динамической регистрации клиентов и управления сессией пользователя.

Заключение

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

Способ


Основное применение


Протоколы


По паролю


Аутентификация пользователей


HTTP, Forms


По сертификатам


Аутентификация пользователей в безопасных приложениях; аутентификация сервисов


SSL/TLS


По одноразовым паролям


Дополнительная аутентификация пользователей (для достижения two-factor authentication)


Forms


По ключам доступа


Аутентификация сервисов и приложений


-


По токенам


Делегированная аутентификация пользователей; делегированная авторизация приложений


SAML, WS-Federation, OAuth, OpenID Connect


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

Автор: Дмитрий Выростков, Solutions Architect в DataArt.

Как ты реализуешь аутентификацию, приятель? / Блог компании Mail.ru Group / Хабр

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

Нельзя отрицать, что в любых приложениях и ОС «аутентификация» — крайне важный элемент обеспечения сохранности пользовательских данных и регулирования доступа к информации. Чтобы понять, какой метод аутентификации для вас лучше, нужно разбираться в достоинствах и недостатках всех методов, а также неплохо представлять, как же они работают.

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

Будем считать, вы уже знаете о том, что большая часть веба/интернета построена на протоколе HTTP. Также вам нужно знать, как работают веб-приложения, что означает аутентификация пользователя в приложении и что такое клиент-серверная архитектура.

Готовы? Поехали.


Аутентификация на основе сессий

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

Чтобы избавиться от этого неудобства, придумали аутентификацию на основе сессий/кук, с помощью которых реализовали отслеживание состояний (stateful). Это означает, что аутентификационная запись или сессия должны храниться и на сервере, и на клиенте. Сервер должен отслеживать активные сессии в базе данных или памяти, а на фронтенде создаётся кука, в которой хранится идентификатор сессии. Это аутентификация на основе куки, самая распространённый и широко известный метод, используемый уже давно.

Процедура аутентификации на основе сессий:


  1. Пользователь вводит в браузере своё имя и пароль, после чего клиентское приложение отправляет на сервер запрос.
  2. Сервер проверяет пользователя, аутентифицирует его, шлёт приложению уникальный пользовательский токен (сохранив его в памяти или базе данных).
  3. Клиентское приложение сохраняет токены в куках и отправляет их при каждом последующем запросе.
  4. Сервер получает каждый запрос, требующий аутентификации, с помощью токена аутентифицирует пользователя и возвращает запрошенные данные клиентскому приложению.
  5. Когда пользователь выходит, клиентское приложение удаляет его токен, поэтому все последующие запросы от этого клиента становятся неаутентифицированными.

У этого метода несколько недостатков.


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

Аутентификация на основе токенов

Аутентификация на основе токенов в последние годы стала очень популярна из-за распространения одностраничных приложений, веб-API и интернета вещей. Чаще всего в качестве токенов используются Json Web Tokens (JWT). Хотя реализации бывают разные, но токены JWT превратились в стандарт де-факто.

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

Процедура аутентификации на основе токенов:


  1. Пользователь вводит имя и пароль.
  2. Сервер проверяет их и возвращает токен (JWT), который может содержать метаданные вроде user_id, разрешений и т. д.
  3. Токен хранится на клиентской стороне, чаще всего в локальном хранилище, но может лежать и в хранилище сессий или кук.
  4. Последующие запросы к серверу обычно содержат этот токен в качестве дополнительного заголовка авторизации в виде Bearer {JWT}. Ещё токен может пересылаться в теле POST-запроса и даже как параметр запроса.
  5. Сервер расшифровывает JWT, если токен верный, сервер обрабатывает запрос.
  6. Когда пользователь выходит из системы, токен на клиентской стороне уничтожается, с сервером взаимодействовать не нужно.

Более подробное описание.

У метода есть ряд преимуществ:


  • Главное преимущество: поскольку метод никак не оперирует состояниями, серверу не нужно хранить записи с пользовательскими токенами или сессиями. Каждый токен самодостаточен, содержит все необходимые для проверки данные, а также передаёт затребованную пользовательскую информацию. Поэтому токены не усложняют масштабирование.
  • В куках вы просто храните ID пользовательских сессий, а JWT позволяет хранить метаданные любого типа, если это корректный JSON.
  • При использовании кук бэкенд должен выполнять поиск по традиционной SQL-базе или NoSQL-альтернативе, и обмен данными наверняка длится дольше, чем расшифровка токена. Кроме того, раз вы можете хранить внутри JWT дополнительные данные вроде пользовательских разрешений, то можете сэкономить и дополнительные обращения поисковые запросы на получение и обработку данных.
    Допустим, у вас есть API-ресурс /api/orders, который возвращает последние созданные приложением заказы, но просматривать их могут только пользователи категории админов. Если вы используете куки, то, сделав запрос, вы генерируете одно обращение к базе данных для проверки сессии, ещё одно обращение — для получения пользовательских данных и проверки, относится ли пользователь к админам, и третье обращение — для получения данных.
    А если вы применяете JWT, то можете хранить пользовательскую категорию уже в токене. Когда сервер запросит его и расшифрует, вы можете сделать одно обращение к базе данных, чтобы получить нужные заказы.
  • У использования кук на мобильных платформах есть много ограничений и особенностей. А токены сильно проще реализовать на iOS и Android. К тому же токены проще реализовать для приложений и сервисов интернета вещей, в которых не предусмотрено хранение кук.

Благодаря всему этому аутентификация на основе токенов сегодня набирает популярность.


Беспарольная аутентификация

Первой реакцией на термин «беспарольная аутентификация» может быть «Как аутентифицировать кого-то без пароля? Разве такое возможно?»

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

Беспарольная аутентификация — это способ конфигурирования процедуры входа и аутентификации пользователей без ввода паролей. Идея такая:

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

Есть похожий метод, при котором вместо одноразовой ссылки по SMS отправляется код или одноразовый пароль. Но тогда придётся объединить ваше приложение с SMS-сервисом вроде twilio (и сервис не бесплатен). Код или одноразовый пароль тоже можно отправлять по почте.

И ещё один, менее (пока) популярный (и доступный только на устройствах Apple) метод беспарольной аутентификации: использовать Touch ID для аутентификации по отпечаткам пальцев. Подробнее о технологии.

Если вы пользуетесь Slack, то уже могли столкнуться с беспарольной аутентификацией.

Medium предоставляет доступ к своему сайту только по почте. Я недавно обнаружил, что Auth0, или Facebook AccountKit, — это отличный вариант для реализации беспарольной системы для вашего приложения.

Что может пойти не так?

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

В чём преимущества?

Как часто вы пользуетесь ссылкой «забыли пароль» для сброса чёртового пароля, который так и не смогли вспомнить после нескольких неудачных попыток входа на сайт / в приложение? Все мы бываем в такой ситуации. Все пароли не упомнишь, особенно если вы заботитесь о безопасности и для каждого сайта делаете отдельный пароль (соблюдая все эти «должен состоять не менее чем из восьми символов, содержать хотя бы одну цифру, строчную букву и специальный символ»). От всего этого вас избавит беспарольная аутентификация. Знаю, вы думаете сейчас: «Я использую менеджер паролей, идиот». Уважаю. Но не забывайте, что подавляющее большинство пользователей не такие техногики, как вы. Это нужно учитывать.

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

Если вы думаете, что какие-то пользователи предпочтут старомодные логин/пароль, то предоставьте им оба варианта, чтобы они могли выбирать.

Сегодня беспарольная аутентификация быстро набирает популярность.


Единая точка входа (Single Sign On, SSO)

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

Этот метод называется единой точкой входа (Single Sign On, SSO).

Реализовать его можно по-разному. Например, использовать центральный сервис для оркестрации единого входа между несколькими клиентами. В случае с Google этот сервис называется Google Accounts. Когда пользователь логинится, Google Accounts создаёт куку, которая сохраняется за пользователем, когда тот ходит по принадлежащим компании сервисам. Как это работает:


  1. Пользователь входит в один из сервисов Google.
  2. Пользователь получает сгенерированную в Google Accounts куку.
  3. Пользователь идёт в другой продукт Google.
  4. Пользователь снова перенаправляется в Google Accounts.
  5. Google Accounts видит, что пользователю уже присвоена кука, и перенаправляет пользователя в запрошенный продукт.

Очень простое описание единой точки входа: пользователь входит один раз и получает доступ ко всем системам без необходимости входить в каждую из них. В этой процедуре используется три сущности, доверяющие другу прямо и косвенно. Пользователь вводит пароль (или аутентифицируется иначе) у поставщика идентификационной информации (identity provider, IDP), чтобы получить доступ к поставщику услуги (service provider (SP). Пользователь доверяет IDP, и SP доверяет IDP, так что SP может доверять пользователю.

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


Аутентификация в соцсетях

Уверен, эта картинка знакома всем:

Это часто называют аутентификацией в соцсетях (Social sign-in) или социальным логином (Social Login). Вы можете аутентифицировать пользователей по их аккаунтам в соцсетях. Тогда пользователям не придётся регистрироваться отдельно в вашем приложении.

Формально социальный логин — это не отдельный метод аутентификации. Это разновидность единой точки входа с упрощением процесса регистрации/входа пользователя в ваше приложение.

Лучшее из двух миров

Пользователи могут войти в ваше приложение одним кликом, если у них есть аккаунт в одной из соцсетей. Им не нужно помнить логины и пароли. Это сильно улучшает опыт использования вашего приложения. Вам как разработчику не нужно волноваться о безопасности пользовательских данных и думать о проверке адресов почты — они уже проверены соцсетями. Кроме того, в соцсетях уже есть механизмы восстановления пароля.

Как использовать

Как разработчик вы должны разбираться в работе этого метода аутентификации. Большинство соцсетей в качестве механизма аутентификации используют авторизацию через OAuth3 (некоторые используют OAuth2, например Twitter). Разберёмся, что такое OAuth. Соцсеть — это сервер ресурсов, ваше приложение — клиент, а пытающийся войти в ваше приложение пользователь — владелец ресурса. Ресурсом называется пользовательский профиль / информация для аутентификации. Когда пользователь хочет войти в ваше приложение, оно перенаправляет пользователя в соцсеть для аутентификации (обычно это всплывающее окно с URL’ом соцсети). После успешной аутентификации пользователь должен дать вашему приложению разрешение на доступ к своему профилю из соцсети. Затем соцсеть возвращает пользователя обратно в ваше приложение, но уже с токеном доступа. В следующий раз приложение возьмёт этот токен и запросит у соцсети информацию из пользовательского профиля. Так работает OAuth (ради простоты я опустил технические подробности).

Для реализации такого механизма вам может понадобиться зарегистрировать своё приложение в разных соцсетях. Вам дадут app_id и другие ключи для конфигурирования подключения к соцсетям. Также есть несколько популярных библиотек/пакетов (вроде Passport, Laravel Socialite и т. д.), которые помогут упростить процедуру и избавят от излишней возни.


Двухфакторная аутентификация (2FA)

Двухфакторная аутентификация (2FA) улучшает безопасность доступа за счёт использования двух методов (также называемых факторами) проверки личности пользователя. Это разновидность многофакторной аутентификации. Наверное, вам не приходило в голову, но в банкоматах вы проходите двухфакторную аутентификацию: на вашей банковской карте должна быть записана правильная информация, и в дополнение к этому вы вводите PIN. Если кто-то украдёт вашу карту, то без кода он не сможет ею воспользоваться. (Не факт! — Примеч. пер.) То есть в системе двухфакторной аутентификации пользователь получает доступ только после того, как предоставит несколько отдельных частей информации.

Другой знакомый пример — двухфакторная аутентификация Mail.Ru, Google, Facebook и т. д. Если включён этот метод входа, то сначала вам нужно ввести логин и пароль, а затем одноразовый пароль (код проверки), отправляемый по SMS. Если ваш обычный пароль был скомпрометирован, аккаунт останется защищённым, потому что на втором шаге входа злоумышленник не сможет ввести нужный код проверки.

Вместо одноразового пароля в качестве второго фактора могут использоваться отпечатки пальцев или снимок сетчатки.

При двухфакторной аутентификации пользователь должен предоставить два из трёх:


  • То, что вы знаете: пароль или PIN.
  • То, что у вас есть: физическое устройство (смартфон) или приложение, генерирующее одноразовые пароли.
  • Часть вас: биологически уникальное свойство вроде ваших отпечатков пальцев, голоса или снимка сетчатки.

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

То есть это универсальное решение? Возможно, нет.

И всё же двухфакторка поможет усилить безопасность аутентификации в вашем приложении. Как реализовать? Возможно, стоит не велосипедить, а воспользоваться существующими решениями вроде Auth0 или Duo.


Аутентификация или авторизация?

Некоторые путают термины «аутентификация» и «авторизация». Это разные вещи.


  • Аутентификация — это проверка вашей личности. Когда вы входите в приложение с именем и паролем, вы аутентифицируетесь.
  • Авторизация — это проверка наличия у вас доступа к чему-либо. Это может быть набор разрешений на какие-то действия. Например, если вы создали в приложении ресурс, то вы можете быть единственным, кому разрешено удалять этот ресурс (потому что вы владелец), а другие пользователи для того не «авторизованы».

Ещё тут?

Поздравляю, вы успешно дочитали длинную, нудную и скучную статью.

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

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

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

Разработка безопасной системы аутентификации пользователей — это по-настоящему сложная задача. Она гораздо масштабнее, чем многие думают. Эту задачу очень легко решить неправильно. Хуже того: ошибки при создании подсистем аутентификации могут повлечь за собой катастрофические последствия. В базовую структуру систем аутентификации и управления пользователями входит всего несколько форм. Из-за этого создание подобных систем может показаться весьма простым делом. Но, как известно, дьявол кроется в деталях. Нужно немало потрудиться для того чтобы сделать такие системы безопасными (и, когда это возможно или даже необходимо, учесть в них требования конфиденциальности персональных данных).

IDaaS


К счастью, у современного веб-разработчика нет необходимости в развёртывании собственной системы для аутентификации пользователей и для управления ими. Сейчас, в 2020 году, существует множество хороших IDaaS-решений (Identity as a Service, идентификация как сервис). Применение таких решения значительно упрощает оснащение веб-проектов возможностями по аутентификации пользователей.

Вот несколько популярных IDaaS-проектов (в алфавитном порядке): Auth0, Azure AD, Google Identity Platform и Okta.

Кроме того, существуют поставщики идентификационной информации, основанной на чём-то наподобие учётных записей пользователей социальных сетей. Это, например, Apple, Facebook, GitHub, Twitter. Разработчикам очень легко внедрять в свои проекты возможности этих систем. Тот, кто работает с провайдерами аутентификации, может очень быстро создать соответствующую подсистему приложения, имеющую доступ к большому массиву данных о пользователях. Но иногда взаимодействие проекта с провайдерами может иметь негативное влияние на конфиденциальность данных пользователей.

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

Чем больше пользователей — тем безопаснее решение


Большинство поставщиков идентификационной информации предлагаю дополнительные возможности, касающиеся безопасности. Такие, как поддержка многофакторной аутентификации (MFA, multi-factor authentication), поддержка сертификатов безопасности или ключей (в том числе — U2F, FIDO2, WebAuthn и прочее подобное).

Не стоит недооценивать важность этих технологий. В соответствии с отчётом Microsoft, включение MFA позволяет предотвратить до 99,9% атак на учётные записи.

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

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

Например, предположим, один из ваших пользователей, живущий в Канаде, входит в систему из дома. А через два часа вход в тот же аккаунт выполняется из Украины. Сервисы поставщика идентификационной информации способны счесть такое поведение подозрительным и могут либо сразу запретить вход, либо предложить пользователю пройти дополнительную верификацию (например, с использованием MFA-токена). Они, кроме того, могут уведомлять пользователей, которые подверглись атаке, или системных администраторов, а возможно — и тех, и других.

Распространённые возражения, высказываемые об использовании сторонних сервисов аутентификации


▍На самом деле, не так уж и сложно создать собственную систему для аутентификации пользователей и для управления ими


Формы для регистрации в проекте и для входа в него — это лишь одна сторона «медали» системы аутентификации. Разработчику, создавая подобную систему, придётся решить гораздо больше задач, чем разработка пары форм.

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

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

То, что правильное управление паролями, это — непростая задача, не должно никого удивлять. А вы знали о том, что управление именами пользователей — это тоже сложно? Например, тот факт, что имена пользователей выглядят одинаково, ещё не означает, что система, при их сравнении, сочтёт их таковыми. В этом выступлении 2018 года высказаны ещё некоторые интересные идеи, касательно того, что может пойти не так при работе с такими «простыми» сущностями, как имена пользователей.

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

▍Использование сервисов аутентификации пользователей не всегда бесплатно, особенно — для крупных проектов


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

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

▍Я — очень опытный разработчик, поэтому знаю о том, как создать безопасную систему аутентификации


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

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

Или, если вы и правда хотите создать собственную систему аутентификации, то вы можете поразмыслить о поступлении на работу в компанию, вроде Microsoft, Auth0 или Facebook с целью улучшения их систем идентификации пользователей.

▍Я хочу держать под контролем пользователей моего проекта


Я, рассматривая данную идею, сразу хочу задать вам вопрос: «А зачем вам это?». Вполне возможно то, что вам это по-настоящему не нужно. Ну, если только вы не разрабатываете новый Facebook. В таком случае данные о пользователях — это ваш самый главный актив, и чем больше таких данных вы соберёте, тем лучше.

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

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

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

С чего начать?


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

Для начала — хорошая новость. Она заключается в том, что все четыре вышеперечисленных провайдера (Auth0, Azure AD, Google Identity Platform, Okta), да и многие другие, используют одни и те же протоколы: OpenID Connect / OAuth 2.0. Это — современные стандартные протоколы, клиентские библиотеки для поддержки которых существуют практически для всех языков программирования и фреймворков.

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

  1. Зарегистрируйте приложение у поставщика идентификационной информации. Вам, после регистрации, выдадут идентификатор (Application ID, Client ID) и секретный ключ (Secret Key, Client Secret).
  2. Задайте разрешения, необходимые вашему приложению. В дополнение к тому, что приложению будет доступен профиль пользователя, вы, что зависит от выбранного провайдера, сможете получить доступ к гораздо большему объёму данных. Сюда может входить, например, доступ к сообщениям пользователей и доступ к их облачному хранилищу (например — через Office 365 или G Suite).
  3. Интегрируйте клиентскую библиотеку сервиса аутентификации в свой проект.

Я не стану пытаться рассказать в подробностях о том, как именно работает механизм OpenID Connect. Но, в целом, работа с сервисами аутентификации выглядит так:
  1. Приложение перенаправляет пользователя на страницу провайдера аутентификации.
  2. Пользователь аутентифицируется и перенаправляется на страницу вашего приложения.
  3. Приложение получает JWT-токен.

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

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

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

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

Использование OpenID Connect в клиент-серверных приложениях


То, как именно в конкретном приложении будет использоваться механизм OpenID Connect, сильно зависит от того, с использованием какого языка и фреймворка создано приложение.

На сайте jwt.io можно найти исчерпывающий список библиотек, которые можно использовать для верификации JWT-токенов.

Для некоторых стеков технологий, кроме того, можно воспользоваться решениями более высокого уровня. Например — это, в среде Node.js/Express, express-jwt или passport.

Использование OpenID Connect на статических сайтах или в нативных приложениях


Статические веб-приложения (их ещё называют «JAMstack-сайтами») и нативные приложения (то есть — настольные или мобильные приложения) тоже могут пользоваться OpenID Connect, но делается это немного не так, как в случае с обычными веб-проектами. В спецификации OAuth 2.0 это называется «implicit flow», или получение токена доступа напрямую от пользователя.

При таком подходе не нужно использовать механизм, в котором применяется секретный ключ (Client Secret). Дело в том, что приложение выполняется на клиенте, поэтому не существует безопасного способа распространения подобных ключей. Здесь применяется следующая последовательность действий:

  1. Приложение перенаправляет пользователя на аутентификационную конечную точку, проверяя, чтобы строка запроса содержала бы scope=id_token.
  2. Пользователь выполняет аутентификацию, пользуясь возможностями поставщика идентификационной информации.
  3. Пользователя перенаправляют к приложению, JWT-токен сессии прикрепляется к URL страницы в виде URL-фрагмента (URL-фрагмент — это то, что следует за знаком #). Он находится в поле, называемом id_token.
  4. Приложение получает JWT-токен из URL-фрагмента и проверяет его. Если токен успешно проходит проверку, пользователь считается аутентифицированным, а это значит, что приложение может использовать сведения о пользователе из токена.

Для того чтобы проверить JWT-токен в статическом веб-приложении можно использовать модуль idtoken-verifier. Настольные и мобильные приложения могут использовать похожие библиотеки. Конкретная библиотека зависит от технологии, использованной при разработке приложения.

При разработке клиент-серверных проектов, таких, как статические веб-ресурсы или нативные приложения, важно обеспечить то, чтобы токен был бы подписан с использованием RSA-SHA256 (в заголовке токена alg должно быть записано RS256). Речь идёт об использовании механизма асимметричного шифрования: поставщик идентификационной информации подписывает токены с использованием секретного ключа, а приложение может проверить токен с использованием публичного ключа. Ещё один распространённый алгоритм, применяемый для подписи токенов, это HMAC-SHA256 (или HS256). Тут используется симметричное шифрование, для подписи и проверки токенов применяется один и тот же ключ. Проблема тут в том, что нельзя организовать безопасное хранение подобных ключей в клиентских приложениях.

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

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

Какие механизмы аутентификации пользователей применяете вы?

Никто (почти) не знает, что такое авторизация / Блог компании Avanpost / Хабр

За время работы архитектором в проектах внедрения IdM я проанализировал десятки реализаций механизмов авторизации как во внутренних решениях компаний, так и в коммерческих продуктах, и могу утверждать, что практически везде при наличии относительно сложных требований они сделаны не правильно или, как минимум, не оптимально. Причиной, на мой взгляд, является низкое внимание и заказчика и разработчиков к данному аспекту на начальных этапах и недостаточная оценка влияния требований. Это косвенно подтверждает повсеместное неправильное использование термина: когда я вижу словосочетание «двухфакторная авторизация», у меня начинаются боли чуть ниже спины. Ради интереса мы проанализировали первые 100 статей на Хабре в выдаче по запросу «авторизация», результат получился неутешительный, боли было много:


В более чем 80% случаев термин употребляется неверно, вместо него следовало бы использовать слово «аутентификация». Далее я попытаюсь объяснить что это такое, и почему крайне важно уделить особое внимание этой теме.

Что же это такое?


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

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

Проблематика


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

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

  1. Пользователь, не имеющий отношения к конкретному договору, не должен его видеть в системе
  2. Автор договора должен видеть его на всех этапах.
  3. Создавать договор имеет право пользователь с грейдом не ниже 10.
  4. Визирующий должен видеть договор, начиная с поступления к нему на этап и далее.
  5. Руководители подразделений должны видеть договоры своих подразделений вверх по иерархии.
  6. Автор договора и руководитель подразделения имеют право отозвать договор на любом этапе согласования.
  7. Руководство и секретариат головного офиса должны видеть документы всех филиалов.
  8. Пользователь, создавший договор, не должен иметь права его завизировать.

От безопасности мы могли бы получить следующие требования:
  1. Знать, кто имеет доступ к конкретному договору.
  2. Знать, кто имел доступ к конкретному договору в заданный момент времени.
  3. Лишать пользователя доступа к ранее доступным документам при изменении его должностных обязанностей.

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

Итак, обозначим, почему эти требования проблемные:

  • Они не стабильны. Вероятность их изменения, даже в краткосрочной перспективе, стремится к 1.
  • Они сквозные. Их реализация влияет на все слои, от дизайна БД до UI.
  • Они лежат в плоскости предметной области. Это ведет к сильной связности механизма авторизации со слоем бизнес-логики. 
  • Они влияют на производительность. 

Пути решения


Решить данную задачу нам помогают разработанные модели управления доступом:

MAC — мандатная модель управления доступом. Доступ субъекта к объекту определяется его уровнем доступа: уровень доступа субъекта должен быть не ниже уровня секретности объекта.

DAC — прямое управление доступом. Доступ субъекта к объекту определяется наличием субъекта в списке доступа (ACL) объекта.

RBAC — ролевая модель управления доступом. Доступ субъекта к объекту определяется наличием у субъекта роли, содержащей полномочия, соответствующие запрашиваемому доступу.

АВАС — атрибутивная модель управления доступом. Доступ субъекта к объекту определяется динамически на основании анализа политик учитывающих значения атрибутов субъекта, объекта и окружения. Сюда же относятся PBAC, RAdAC, CBAC, с некоторыми нюансами (шикарный обзор от CUSTIS).

Их крайне рекомендуется использовать в первозданном виде, не изобретая велосипед. Достаточно часто в сложных информационных системах используется комбинация моделей. Например, популярна комбинация ACL + RBAC, когда роль включается в список доступа. Однако, правильное применение готовых моделей — тоже не простая задача. Не всем удается правильно выбрать модель, отделить ее от бизнес-логики и достичь приемлемой производительности механизма авторизации.

Для реализации озвученных выше в разделе «Проблематика» требований, на первый взгляд, я бы выбрал комбинацию PBAC + ACL. Требования могли бы быть реализованы следующим образом:


Перечисленные требования ИБ без всяких проблем реализуются с использованием ACL, однако бизнес-требования 5 и 7 мы реализуем с помощью PBAC. Так что для реализации требований ИБ 1 и 2 придется добавить к ним журнал или аналогичный механизм, поскольку при всей своей красоте динамические правила плохо аудируются:

Итого


Авторизация — незаслуженно обойденная вниманием тема, как в публикациях, так и непосредственно в процессе разработки. Двухфакторную аутентификацию по СМС к сайту прикрутит и ребенок. Правильно реализовать авторизацию в корпоративной системе, не наделав костылей — сложнейшая задача, о которую ломают копья сеньоры и архитекторы, а множество популярных коммерческих продуктов (к примеру, Atlassian Jira) стоят на костылях благодаря сложности требований. 

Мы планируем серию статей, посвященных моделям авторизации и предмету в целом. Будем рады вопросам и предложениям по темам для рассмотрения.

Как при помощи токена сделать Windows домен безопаснее? Часть 1

Кто-то из вас наверняка слышал про инцидент , который был обнародован совсем недавно. Американский производитель полупроводников Allegro MicroSystem LLC подал в суд на своего бывшего IT-специалиста за саботаж. Нимеш Пател, проработавший в компании 14 лет, уничтожил важные финансовые данные в первую неделю нового фискального года.

Как это произошло?

Через две недели после своего увольнения Пател зашел на территорию штаб-квартиры компании в Вустере (штат Массачусетс, США) с целью поймать корпоративную сеть Wi-Fi. Используя учетные данные бывшего коллеги и рабочий ноутбук, Пател авторизовался в корпоративной сети. Затем он внедрил в модуль Oracle код и запрограммировал его выполнение на 1 апреля 2016 года — первую неделю нового финансового года. Код предназначался для копирования определенных заголовков или указателей в отдельную таблицу базы данных и следующего удаления их из модуля. Ровно 1 апреля данные были удалены из системы. И поскольку злоумышленник авторизовался в сети Allegro легально, его действия были замечены не сразу.

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

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

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

В первой статье мы объясним как настроить строгую двухфакторную аутентификацию с использованием PKI при входе в доменную учетную запись в Windows.

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


Двухфакторная аутентификация

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

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

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

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


Токен и смарт-карта

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

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

На фотографии изображена типичная смарт-карта и считыватель.


Однако вернемся к корпоративной безопасности.

А начнем мы с домена Windows, ведь в большинстве компаний в России корпоративная сеть построена именно вокруг него.

Как известно, политики Windows-домена, настройки пользователей, настройки групп в Active Directory предоставляют и разграничивают доступ к огромному количеству приложений и сетевых сервисов.

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


Почему двухфакторная аутентификация в домене по токену с PIN-кодом безопаснее обычной парольной схемы?

PIN-код привязан к определенному устройству, в нашем случае к токену. Знание PIN-кода само по себе ничего не дает.

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

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

Токен является уникальным некопируемым физическим объектом. Им обладает легитимный пользователь. Двухфакторную аутентификацию по токену можно обойти только тогда, когда администратор намеренно или по недосмотру оставил для этого «лазейки» в системе.


Преимущества входа в домен по токену

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

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

При использовании токена для пользователя вход в систему выглядит следующим образом: после загрузки компьютера, он просто подключает токен к USB-порту компьютера, вводит 4-6 цифр и нажимает кнопку Enter. Скорость ввода цифр у обычных людей выше, чем скорость ввода букв. Поэтому PIN-код вводится быстрее.


Токены позволяют решить проблему «брошенного рабочего места» — когда пользователь уходит со своего рабочего места и забывает выйти из своей учетной записи.

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


Недостатки, куда же без них

Токены или смарт-карты не бесплатные (решается бюджетом).

Их нужно учитывать, администрировать и обслуживать (решается системами управления токенами и смарт-картами).

Некоторые информационные системы могут «из коробки» не поддерживать аутентификацию по токенам (решается системами типа Single Sign-On — предназначенными для организации возможности использования единой учетной записи для доступа к любым ресурсам области).


Настройка двухфакторной аутентификации в домене Windows

Теоретическая часть:

Служба каталога Active Directory поддерживает возможность аутентификации с помощью смарт-карты и токена, начиная с Windows 2000. Она заложена в расширении PKINIT (public key initialization — инициализация открытого ключа) для протокола Kerberos RFC 4556 .

Протокол Kerberos был специально разработан для того, чтобы обеспечить надежную аутентификацию пользователей. Он может использовать централизованное хранение аутентификационных данных и является основой для построения механизмов Single Sing-On. Протокол основан на ключевой сущности Ticket (билет).


Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей).

Когда пользователь выполняет первичную аутентификацию после успешного подтверждения его подлинности, KDC выдает первичное удостоверение пользователя для доступа к сетевым ресурсам — Ticket Granting Ticket (TGT).

В дальнейшем при обращении к отдельным ресурсам сети, пользователь, предъявляет TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Ticket Granting Service (TGS).

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

Расширение PKINIT позволяет использовать двухфакторную аутентификацию по токенам или смарт-картам на этапе предаутентификации Kerberos.

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

Все контроллеры доменов должны иметь установленный сертификат Domain Controller Authentication, или Kerberos Authentication, т. к. реализуется процесс взаимной аутентификации клиента и сервера.

Практика:

Приступим к настройке.

Сделаем так, чтобы в домен под вашей учетной записью можно было зайти только по предъявлению токена и зная PIN-код.

Для демонстрации мы будем использовать Рутокен ЭЦП PKI производства компании «Актив».


1 Этап — Настройка домена Первым делом установим службы сертификации.

Дисклеймер.

Эта статья не является туториалом по внедрению корпоративного PKI. Вопросы проектирования, разворачивания и грамотного применения PKI тут не рассматриваются ввиду необъятности этой темы.

Все контроллеры доменов и все клиентские компьютеры в рамках леса, где осуществляется внедрение такого решения, обязательно должны доверять корневому Удостоверяющему Центру (Центру Сертификации).

Задача центра сертификации — подтверждать подлинность ключей шифрования с помощью сертификатов электронной подписи.

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

Удостоверяющий центр, выдающий сертификаты для использования смарт-карт или токенов, должен быть помещен в хранилище NT Authority.

Зайдите в Диспетчер сервера и выберите «Добавить роли и компоненты».

При добавлении ролей сервера выберите «Службы сертификации Active Directory» (Microsoft категорически рекомендует не делать это на контроллере домена, дабы не огрести проблем с производительностью). В открывшемся окне выберите «Добавить компоненты» и выберите пункт «Центр сертификации».

На странице для подтверждения установки компонентов нажмите «Установить».

2 Этап — Настройка входа в домен с помощью токена

Для входа в систему нам понадобится сертификат, который содержит идентификаторы Smart Card Logon и Client Authentication.

Сертификат для смарт-карт или токенов также должен содержать UPN пользователя (суффикс имени участника-пользователя). По умолчанию суффиксом имени участника-пользователя для учетной записи является DNS-имя домена, которое содержит учетную запись пользователя.

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

В сертификате должен быть указан путь к точке распространения списка отзыва сертификатов (CRL distribution point). Такой файл содержит список сертификатов с указанием серийного номера сертификата, даты отзыва и причины отзыва. Он используется для передачи сведений об отозванных сертификатах пользователям, компьютерам и приложениям, пытающимся проверить подлинность сертификата.

Настроим установленные службы сертификации. В правом верхнем углу нажмите на желтый треугольник с восклицательным знаком и щелкните «Настроить службы сертификации…».


В окне «Учетные данные» выберите необходимые учетные данные пользователя для настройки роли. Выберите «Центр сертификации».

Выберите «ЦС предприятия».

ЦС предприятия интегрированы с AD. Они публикуют сертификаты и списки отзыва сертификатов в AD.

Укажите тип «Корневой ЦС».

На следующем этапе выберите «Создать новый закрытый ключ».

Выберите период действия сертификата.

3 этап — Добавление шаблонов сертификатов

Для добавления шаблонов сертификатов откройте Панель управления, выберите пункт «Администрирование» и откройте Центр сертификации.

Щелкните по названию папки «Шаблоны сертификатов», выберите пункт «Управление».

Щелкните по названию шаблона «Пользователь со смарт-картой» и выберите пункт «Скопировать шаблон». На следующих скриншотах показано, какие параметры в окне «Свойства нового шаблона» необходимо изменить.


Если в списке поставщиков нет «Aktiv ruToken CSP v1.0», то необходимо установить комплект «Драйверы Рутокен для Windows».

Начиная с Windows Server 2008 R2 вместо специального провайдера от производителя можно использовать «Microsoft Base Smart Card Crypto Provider».

Для устройств Рутокен библиотека «минидрайвера», поддерживающая «Microsoft Base Smart Card Crypto Provider», распространяется через Windows Update.

Проверить установился ли «минидрайвер» на вашем сервере можно подключив Рутокен к нему и посмотрев в диспетчер устройств.


Если «минидрайвера» по каким-то причинам нет, его можно установить принудительно, инсталлировав комплект «Драйверы Рутокен для Windows», а после этого воспользоваться «Microsoft Base Smart Card Crypto Provider».

Комплект «Драйверы Рутокен для Windows» распространяется бесплатно с сайта Рутокен .


Добавьте два новых шаблона «Агент сертификации» и «Пользователь с Рутокен».

Для этого выйдите из окна «Управления шаблонами». Нажмите правой кнопкой мыши на «Шаблоны сертификатов» и выберите пункт меню «Создать» и подпункт «Выдаваемый шаблон сертификата».



Далее выберите «Агент регистрации» и «Пользователь с Rutoken» и нажмите «ОК».

В результате названия этих шаблонов отобразятся в центре сертификации.

Далее нам необходимо выписать сертификат администратору домена. Откройте службу «Выполнить» и укажите команду mmc. Добавьте оснастку «Сертификаты».

В окне «Оснастки диспетчера сертификатов» выберите «моей учетной записи пользователя». В окне «Добавление и удаление оснастки» подтвердите добавление сертификатов.

Выберите папку «Сертификаты».


Запросите новый сертификат. Откроется страница для регистрации сертификата. На этапе запроса сертификата выберите политику регистрации «Администратор» и нажмите «Заявка».


Таким же образом запросите сертификат для Агента регистрации.

Чтобы запросить сертификат для определенного пользователя щелкните «Сертификаты», выберите пункт «Зарегистрироваться от имени...».


В окне для запроса сертификата установите флажок «Пользователь с Рутокен».

Теперь необходимо выбрать пользователя.

В поле «Введите имена выбранных объектов» укажите имя пользователя в домене и нажмите «Проверить имя».

В окне для выбора пользователя нажмите «Заявка».

В раскрывающемся списке выберите имя токена и укажите PIN-код.


Таким же образом выберите сертификаты для других пользователей в домене.

4 этап — Настройка учетных записей пользователей

Для настройки учетных записей откройте список пользователей и компьютеров AD.

Выберите папку Users и пункт «Свойства».


Перейдите на вкладку «Учетные записи», установите флажок «Для интерактивного входа в сеть нужна смарт-карта».


Настройте политики безопасности. Для этого откройте Панель управления и выберите пункт «Администрирование». Откройте меню для управления групповой политикой.

В левой части окна «Управление групповой политикой» щелкните «Default Domain Policy» и выберите пункт «Изменить».


В левой части окна «Редактор управления групповыми политиками» выберите пункт «Параметры безопасности».


Откройте политику «Интерактивный вход в систему: требовать смарт-карту».

На вкладке «Параметры политики безопасности» установите флажки «Определить следующий параметр политики» и «Включен».

Откройте политику «Интерактивный вход в систему: поведение при извлечении смарт-карты».

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

Перезагрузите компьютер. И при следующей попытке аутентификации в домене уже можно будет использовать токен и его PIN-код.


BINGO!

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

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

90000 Authentication and authorization - Azure App Service 90001 90002 90003 90004 07/08/2020 90005 90006 90003 7 minutes to read 90006 90003 90006 90011 90012 In this article 90013 90014 Note 90015 90014 At this time, ASP.NET Core does not currently support populating the current user with the Authentication / Authorization feature.90015 90014 Azure App Service provides built-in authentication and authorization support, so you can sign in users and access data by writing minimal or no code in your web app, RESTful API, and mobile back end, and also Azure Functions. This article describes how App Service helps simplify authentication and authorization for your app. 90015 90014 Secure authentication and authorization require deep understanding of security, including federation, encryption, JSON web tokens (JWT) management, grant types, and so on.App Service provides these utilities so that you can spend more time and energy on providing business value to your customer. 90015 90014 Important 90015 90014 You're not required to use this feature for authentication and authorization. You can use the bundled security features in your web framework of choice, or you can write your own utilities. However, keep in mind that Chrome 80 is making breaking changes to its implementation of SameSite for cookies (release date around March 2020), and custom remote authentication or other scenarios that rely on cross-site cookie posting may break when client Chrome browsers are updated .The workaround is complex because it needs to support different SameSite behaviors for different browsers. 90015 90014 The ASP.NET Core 2.1 and above versions hosted by App Service are already patched for this breaking change and handle Chrome 80 and older browsers appropriately. In addition, the same patch for ASP.NET Framework 4.7.2 is being deployed on the App Service instances throughout January 2020. For more information, including how to know if your app has received the patch, see Azure App Service SameSite cookie update.90015 90014 For information specific to native mobile apps, see User authentication and authorization for mobile apps with Azure App Service. 90015 90030 How it works 90031 90014 The authentication and authorization module runs in the same sandbox as your application code. When it's enabled, every incoming HTTP request passes through it before being handled by your application code. 90015 90014 90015 90014 This module handles several things for your app: 90015 90038 90003 Authenticates users with the specified provider 90006 90003 Validates, stores, and refreshes tokens 90006 90003 Manages the authenticated session 90006 90003 Injects identity information into request headers 90006 90011 90014 The module runs separately from your application code and is configured using app settings.No SDKs, specific languages, or changes to your application code are required. 90015 90012 User / Application claims 90013 90014 For all language frameworks, App Service makes the claims in the incoming token (whether that be from an authenticated end user or a client application) available to your code by injecting them into the request headers. For ASP.NET 4.6 apps, App Service populates ClaimsPrincipal.Current with the authenticated user's claims, so you can follow the standard .NET code pattern, including the 90053 [Authorize] 90054 attribute.Similarly, for PHP apps, App Service populates the 90053 _SERVER [ 'REMOTE_USER'] 90054 variable. For Java apps, the claims are accessible from the Tomcat servlet. 90015 90014 For Azure Functions, 90053 ClaimsPrincipal.Current 90054 is not populated for .NET code, but you can still find the user claims in the request headers, or get the 90053 ClaimsPrincipal 90054 object from the request context or even through a binding parameter. See working with client identities for more information. 90015 90014 For more information, see Access user claims.90015 90012 Token store 90013 90014 App Service provides a built-in token store, which is a repository of tokens that are associated with the users of your web apps, APIs, or native mobile apps. When you enable authentication with any provider, this token store is immediately available to your app. If your application code needs to access data from these providers on the user's behalf, such as: 90015 90038 90003 post to the authenticated user's Facebook timeline 90006 90003 read the user's corporate data using the Microsoft Graph API 90006 90011 90014 You typically must write code to collect, store, and refresh these tokens in your application.With the token store, you just retrieve the tokens when you need them and tell App Service to refresh them when they become invalid. 90015 90014 The ID tokens, access tokens, and refresh tokens are cached for the authenticated session, and they're accessible only by the associated user. 90015 90014 If you do not need to work with tokens in your app, you can disable the token store. 90015 90012 Logging and tracing 90013 90014 If you enable application logging, you will see authentication and authorization traces directly in your log files.If you see an authentication error that you did not expect, you can conveniently find all the details by looking in your existing application logs. If you enable failed request tracing, you can see exactly what role the authentication and authorization module may have played in a failed request. In the trace logs, look for references to a module named 90053 EasyAuthModule_32 / 64 90054. 90015 90030 Identity providers 90031 90014 App Service uses federated identity, in which a third-party identity provider manages the user identities and authentication flow for you.Five identity providers are available by default: 90015 90014 When you enable authentication and authorization with one of these providers, its sign-in endpoint is available for user authentication and for validation of authentication tokens from the provider. You can provide your users with any number of these sign-in options with ease. 90015 90014 A legacy extensibility path exists for integrating with other identity providers or a custom auth solution, but this is not recommended. Instead, consider using the OpenID Connect support.90015 90030 Authentication flow 90031 90014 The authentication flow is the same for all providers, but differs depending on whether you want to sign in with the provider's SDK: 90015 90038 90003 Without provider SDK: The application delegates federated sign-in to App Service. This is typically the case with browser apps, which can present the provider's login page to the user. The server code manages the sign-in process, so it is also called 90102 server-directed flow 90103 or 90102 server flow 90103.This case applies to browser apps. It also applies to native apps that sign users in using the Mobile Apps client SDK because the SDK opens a web view to sign users in with App Service authentication. 90006 90003 With provider SDK: The application signs users in to the provider manually and then submits the authentication token to App Service for validation. This is typically the case with browser-less apps, which can not present the provider's sign-in page to the user. The application code manages the sign-in process, so it is also called 90102 client-directed flow 90103 or 90102 client flow 90103.This case applies to REST APIs, Azure Functions, and JavaScript browser clients, as well as browser apps that need more flexibility in the sign-in process. It also applies to native mobile apps that sign users in using the provider's SDK. 90006 90011 90014 The table below shows the steps of the authentication flow. 90015 90116 90117 90118 90119 Step 90120 90119 Without provider SDK 90120 90119 With provider SDK 90120 90125 90126 90127 90118 90129 1. Sign user in 90130 90129 Redirects client to 90053 /.auth / login / 90054. 90130 90129 Client code signs user in directly with provider's SDK and receives an authentication token. For information, see the provider's documentation. 90130 90125 90118 90129 2. Post-authentication 90130 90129 Provider redirects client to 90053 /.auth/login//callback 90054. 90130 90129 Client code posts token from provider to 90053 /.auth/login/ 90054 for validation. 90130 90125 90118 90129 3. Establish authenticated session 90130 90129 App Service adds authenticated cookie to response.90130 90129 App Service returns its own authentication token to client code. 90130 90125 90118 90129 4. Serve authenticated content 90130 90129 Client includes authentication cookie in subsequent requests (automatically handled by browser). 90130 90129 Client code presents authentication token in 90053 X-ZUMO-AUTH 90054 header (automatically handled by Mobile Apps client SDKs). 90130 90125 90168 90169 90014 For client browsers, App Service can automatically direct all unauthenticated users to 90053 /.auth / login / 90054. You can also present users with one or more 90053 /.auth/login/ 90054 links to sign in to your app using their provider of choice. 90015 90030 Authorization behavior 90031 90014 In the Azure portal, you can configure App Service authorization with a number of behaviors when incoming request is not authenticated. 90015 90014 90015 90014 The following headings describe the options. 90015 90012 Allow Anonymous requests (no action) 90013 90014 This option defers authorization of unauthenticated traffic to your application code.For authenticated requests, App Service also passes along authentication information in the HTTP headers. 90015 90014 This option provides more flexibility in handling anonymous requests. For example, it lets you present multiple sign-in providers to your users. However, you must write code. 90015 90012 Allow only authenticated requests 90013 90014 The option is 90193 Log in with 90194. App Service redirects all anonymous requests to 90053 /.auth/login/ 90054 for the provider you choose.If the anonymous request comes from a native mobile app, the returned response is an 90053 HTTP 401 Unauthorized 90054. 90015 90014 With this option, you do not need to write any authentication code in your app. Finer authorization, such as role-specific authorization, can be handled by inspecting the user's claims (see Access user claims). 90015 90014 Caution 90015 90014 Restricting access in this way applies to all calls to your app, which may not be desirable for apps wanting a publicly available home page, as in many single-page applications.90015 90014 Note 90015 90014 Authentication / Authorization was previously known as Easy Auth. 90015 90030 More resources 90031 90014 Tutorial: Authenticate and authorize users end-to-end in Azure App Service (Windows) 90213 Tutorial: Authenticate and authorize users end-to-end in Azure App Service for Linux 90213 Customize authentication and authorization in App Service .NET Core integration of Azure AppService EasyAuth (3rd party) Getting Azure App Service authentication working with.NET Core (3rd party) 90015 90014 Provider-specific how-to guides: 90015 .90000 User authentication 90001 90002 StoreFront supports a number of different authentication methods for users accessing stores; although, not all are available depending on the user access method and their network location. For security reasons, some authentication methods are disabled by default when you create your first store.For more information about enabling and disabling user authentication methods, see Create and configure the authentication service. 90003 90004 User name and password 90005 90002 Users enter their credentials and are authenticated when they access their stores. Explicit authentication is enabled by default. All user access methods support explicit authentication. 90003 90002 When a user employs Citrix Gateway to access Citrix Receiver for Web, Citrix Gateway handles the logon and password change at expiration.Users can make elective password changes with the Citrix Receiver for Web UI. After an elective password change, the Citrix Gateway session terminates and the user must log on again. Citrix Receiver for Linux or Citrix Workspace app for Linux users can change only expired passwords. 90003 90004 SAML authentication 90005 90002 Users authenticate to a SAML Identity Provider and are automatically logged on when they access their stores. StoreFront can support SAML authentication directly within the corporate network, without the need to go through Citrix Gateway.90003 90002 SAML (Security Assertion Markup Language) is an open standard used by identity and authentication products such as Microsoft AD FS (Active Directory Federation Services). With the integration of SAML authentication through StoreFront, administrators can allow users to, for example, log on once to their corporate network and then get single sign-on to their published apps. 90003 90002 Requirements: 90003 90018 90019 Implementation of the Citrix Federated Authentication Service.90020 90019 SAML 2.0-compliant identity providers (IdPs): 90018 90019 Microsoft AD FS v4.0 (Windows Server 2016) using SAML bindings only (not WS-Federation bindings). For more information, see AD FS Deployment and AD FS Operations. 90020 90019 Microsoft AD FS v3.0 (Windows Server 2012 R2) 90020 90019 Citrix Gateway (configured as an IdP) 90020 90029 90020 90019 Configure SAML authentication in StoreFront using the StoreFront management console in a new deployment (see Create a new deployment), or in an existing deployment (see Configure the authentication service).You can also configure SAML authentication using PowerShell cmdlets, see StoreFront SDK. 90020 90019 Citrix Receiver (4.6 and later) or Citrix Workspace app for Windows, or Citrix Receiver for Web. 90020 90029 90002 Using SAML authentication with Citrix Gateway is currently supported with Receiver for Web sites. 90003 90004 Domain pass-through 90005 90002 Users authenticate to their domain-joined Windows computers, and their credentials are used to log them on automatically when they access their stores.90003 90002 When you install StoreFront, domain pass-through authentication is disabled by default. You can enable domain pass-through authentication for users connecting to stores through Citrix Workspace app and XenApp Services URLs. Citrix Receiver for Web sites support domain pass-through authentication for Internet Explorer, Microsoft Edge, Mozilla Firefox, and Google Chrome on domain-joined Windows client machines. 90003 90044 To enable domain pass-through authentication 90045 90046 90019 Install Citrix Receiver for Windows or Citrix Workspace app for Windows or the Citrix Online plug-in for Windows on user devices.Ensure that pass-through authentication is enabled. 90020 90019 In the Citrix Receiver for Web site node in the administration console, enable domain pass-through authentication. 90020 90019 Configure SSON on Citrix Receiver for Windows or Citrix Workspace app for Windows, described in Configure domain pass-through authentication. Citrix Workspace app for HTML5 does not support domain pass-through authentication. 90020 90019 Windows 'default behavior is "Automatic logon only in the Intranet zone."For Internet Explorer, Mozilla Firefox and Google Chrome, either configure your Citrix Receiver for Web sites as Intranet sites using the Internet Options, or enable automatic logon for the Trusted zone. For Microsoft Edge you must configure your Citrix Receiver for Web sites as Intranet sites. 90020 90019 For Mozilla Firefox, modify the browser advanced settings to trust the Citrix Receiver for Windows or Citrix Workspace app for Windows URI. 90056 90002 Warning: 90003 90002 Editing the advanced settings incorrectly can cause serious problems.Make edits at your own risk. 90003 90061 90046 90019 Start Firefox, enter 90064 about: config 90065 in the address field and select "I accept the risk!" 90020 90019 Type 90064 ntlm 90065 to the search box. 90020 90019 Double-click on "network.automatic-ntlm-auth.trusted-uris" and type the Citrix Receiver for Windows or Citrix Workspace app for Windows site URL to the pop-up dialog. 90020 90019 Click 90064 OK 90065. 90020 90077 90020 90077 90004 Pass-through from Citrix Gateway 90005 90002 Users authenticate to Citrix Gateway and are automatically logged on when they access their stores.Pass-through from Citrix Gateway authentication is enabled by default when you first configure remote access to a store. Users can connect through Citrix Gateway to stores using Citrix Workspace app or Citrix Receiver for Web sites. For more information about configuring StoreFront for Citrix Gateway, see Add a Citrix Gateway connection. 90003 90002 StoreFront supports pass-through with the following Citrix Gateway authentication methods. 90003 90018 90019 90064 Security token. 90065 Users log on to Citrix Gateway using passcodes that are derived from tokencodes generated by security tokens combined, in some cases, with personal identification numbers.If you enable pass-through authentication by security token only, ensure that the resources you make available do not require additional or alternative forms of authentication, such as users 'Microsoft Active Directory domain credentials. 90020 90019 90064 Domain and security token. 90065 Users logging on to Citrix Gateway are required to enter both their domain credentials and security token passcodes. 90020 90019 90064 Client certificate. 90065 Users log on to Citrix Gateway and are authenticated based on the attributes of the client certificate presented to Citrix Gateway.Configure client certificate authentication to enable users to log on to Citrix Gateway using smart cards. Client certificate authentication can also be used with other authentication types to provide double-source authentication. 90020 90029 90002 StoreFront uses the Citrix Gateway authentication service to provide pass-through authentication for remote users so that they only need to enter their credentials once. However, by default, pass-through authentication is only enabled for users logging on to Citrix Gateway with a password.To configure pass-through authentication from Citrix Gateway to StoreFront for smart card users, delegate credential validation to Citrix Gateway. For more information, see Create and configure the authentication service. 90003 90002 Users can connect to stores within Citrix Workspace app with pass-through authentication through a Secure Sockets Layer (SSL) virtual private network (VPN) tunnel using the Citrix Gateway plug-in. Remote users who can not install the Citrix Gateway plug-in can use clientless access to connect to stores within Citrix Workspace app with pass-through authentication.To use clientless access to connect to stores, users require a version of Citrix Workspace app that supports clientless access. 90003 90002 Additionally, you can enable clientless access with pass-through authentication to Citrix Receiver for Web sites. To do this, configure Citrix Gateway to act as a secure remote proxy. Users log on to Citrix Gateway directly and use the Citrix Receiver for Web site to access their applications without needing to authenticate again. 90003 90002 Users connecting with clientless access to App Controller resources can only access external software-as-a-service (SaaS) applications.To access internal web applications, remote users must use the Citrix Gateway plug-in. 90003 90002 If you configure double-source authentication to Citrix Gateway for remote users accessing stores from within Citrix Workspace app, you must create two authentication policies on Citrix Gateway. Configure RADIUS (Remote Authentication Dial-In User Service) as the primary authentication method and LDAP (Lightweight Directory Access Protocol) as the secondary method. Modify the credential index to use the secondary authentication method in the session profile so that LDAP credentials are passed to StoreFront.When you add the Citrix Gateway appliance to your StoreFront configuration, set the Logon type to Domain and security token. For more information, see http://support.citrix.com/article/CTX125364 90003 90002 To enable multidomain authentication through Citrix Gateway to StoreFront, set SSO Name Attribute to userPrincipalName in the Citrix Gateway LDAP authentication policy for each domain. You can require users to specify a domain on the Citrix Gateway logon page so that the appropriate LDAP policy to use can be determined.When you configure the Citrix Gateway session profiles for connections to StoreFront, do not specify a single sign-on domain. You must configure trust relationships between each of the domains. Ensure that you allow users to log on to StoreFront from any domain by not restricting access to explicitly trusted domains only. 90003 90002 Where supported by your Citrix Gateway deployment, you can use SmartAccess to control user access to Citrix Virtual Apps and Desktops resources on the basis of Citrix Gateway session policies.For more information about SmartAccess, see How SmartAccess works for Citrix Virtual Apps and Desktops. 90003 90004 Smart cards 90005 90002 Users authenticate using smart cards and PINs when they access their stores. When you install StoreFront, smart card authentication is disabled by default. Smart card authentication can be enabled for users connecting to stores through Citrix Workspace app, Citrix Receiver for Web, and XenApp Services URLs. 90003 90002 Use smart card authentication to streamline the logon process for your users while also enhancing the security of user access to your infrastructure.Access to the internal corporate network is protected by certificate-based two-factor authentication using public key infrastructure. Private keys are protected by hardware controls and never leave the smart card. Your users get the convenience of accessing their desktops and applications from a range of corporate devices using their smart cards and PINs. 90003 90002 You can use smart cards for user authentication through StoreFront to desktops and applications provided by Citrix Virtual Apps and Desktops.Smart card users logging on to StoreFront can also access applications provided by App Controller. However, users must authenticate again to access App Controller web applications that use client certificate authentication. 90003 90002 To enable smart card authentication, users 'accounts must be configured either within the Microsoft Active Directory domain containing the StoreFront servers or within a domain that has a direct two-way trust relationship with the StoreFront server domain. Multi-forest deployments involving two-way trusts are supported.90003 90002 The configuration of smart card authentication with StoreFront depends on the user devices, the clients installed, and whether the devices are domain-joined. In this context, domain-joined means devices that are joined to a domain within the Active Directory forest containing the StoreFront servers. 90003 90044 Use smart cards with Citrix Receiver for Windows or Citrix Workspace app for Windows 90045 90002 Users with devices running Citrix Receiver for Windows or Citrix Workspace app for Windows can authenticate using smart cards, either directly or through Citrix Gateway.Both domain-joined and non-domain-joined devices can be used, although the user experience is slightly different. 90003 90002 The figure shows the options for smart card authentication through Citrix Receiver for Windows or Citrix Workspace app for Windows. 90003 90002 90133 90003 90002 For local users with domain-joined devices, you can configure smart card authentication so that users are only prompted for their credentials once. Users log on to their devices using their smart cards and PINs and, with the appropriate configuration in place, are not prompted for their PINs again.Users are silently authenticated to StoreFront and also when they access their desktops and applications. To achieve this, you configure Citrix Receiver for Windows or Citrix Workspace app for Windows for pass-through authentication and enable domain pass-through authentication to StoreFront. 90003 90002 Users log on to their devices and then authenticate to Citrix Receiver for Windows or Citrix Workspace app for Windows using their PINs. There is no further PIN prompts when they try to start apps and desktops 90003 90002 Because users of non-domain-joined devices log on to Citrix Receiver for Windows or Citrix Workspace app for Windows directly, you can enable users to fall back to explicit authentication.If you configure both smart card and explicit authentication, users are initially prompted to log on using their smart cards and PINs but have the option to select explicit authentication if they experience any issues with their smart cards. 90003 90002 Users connecting through Citrix Gateway must log on using their smart cards and PINs at least twice to access their desktops and applications. This applies to both domain-joined and non-domain-joined devices. Users authenticate using their smart cards and PINs, and, with the appropriate configuration in place, are only prompted to enter their PINs again when they access their desktops and applications.To achieve this, you enable pass-through with Citrix Gateway authentication to StoreFront and delegate credential validation to Citrix Gateway. Then, create an additional Citrix Gateway virtual server through which you route user connections to resources. In the case of domain-joined devices, you must also configure Citrix Receiver for Windows or Citrix Workspace app for Windows for pass-through authentication. 90003 90056 90002 90064 Note: 90065 90003 90002 If you are using Citrix Receiver for Windows or Citrix Workspace app for Windows, you can set up a second vServer and use the optimal gateway routing feature to remove the need for PIN prompts when starting apps and desktops.90003 90061 90002 Users can log on to Citrix Gateway using either their smart cards and PINs, or with explicit credentials. This enables you to provide users with the option to fall back to explicit authentication for Citrix Gateway logons. Configure pass-through authentication from Citrix Gateway to StoreFront and delegate credential validation to Citrix Gateway for smart card users so that users are silently authenticated to StoreFront. 90003 90044 Use smart cards with XenApp Services URLs 90045 90002 Users of PCs running the Citrix Desktop Lock can authenticate using smart cards.Unlike other access methods, pass-through of smart card credentials is automatically enabled when smart card authentication is configured for a XenApp Services URL. 90003 90002 The figure shows smart card authentication from a domain-joined device running the Citrix Desktop Lock. 90003 90002 90160 90003 90002 Users log on to their devices using their smart cards and PINs. The Citrix Desktop Lock then silently authenticates users to StoreFront through the XenApp Services URL. Users are automatically authenticated when they access their desktops and applications, and are not prompted for their PINs again.90003 90044 Use smart cards with Citrix Receiver for Web 90045 90002 You can enable smart card authentication to Citrix Receiver for Web from the StoreFront Administration Console. 90003 90046 90019 Select the Citrix Receiver for Web node in the left panel. 90020 90019 Select the site you want to use smart card authentication. 90020 90019 Select the Choose Authentication Methods task in the right panel. 90020 90019 Check the Smart card checkbox in the popup dialog screen and click OK.90020 90077 90002 If you enable pass-through with smart card authentication to Citrix Virtual Apps and Desktops for Citrix Receiver for Windows or Citrix Workspace app for Windows users with domain-joined devices who do not access stores through Citrix Gateway, this setting applies to all users of the store. To enable both domain pass-through and pass-through with smart card authentication to desktops and applications, you must create separate stores for each authentication method. Your users must then connect to the appropriate store for their method of authentication.90003 90002 If you enable pass-through with smart card authentication to Citrix Virtual 90003.90000 Django Tutorial Part 8: User authentication and permissions - Learn web development 90001 90002 In this tutorial, we'll show you how to allow users to log in to your site with their own accounts, and how to control what they can do and see based on whether or not they are logged in and their 90003 permissions 90004. As part of this demonstration, we'll extend the LocalLibrary website, adding login and logout pages, and user- and staff-specific pages for viewing books that have been borrowed.90005 90006 Overview 90007 90002 Django provides an authentication and authorization ( "permission") system, built on top of the session framework discussed in the previous tutorial, that allows you to verify user credentials and define what actions each user is allowed to perform. The framework includes built-in models for 90009 Users 90010 and 90009 Groups 90010 (a generic way of applying permissions to more than one user at a time), permissions / flags that designate whether a user may perform a task, forms and views for logging in users, and view tools for restricting content.90005 90002 90015 Note 90016: According to Django the authentication system aims to be very generic, and so does not provide some features provided in other web authentication systems. Solutions for some common problems are available as third-party packages. For example, throttling of login attempts and authentication against third parties (e.g. OAuth). 90005 90002 In this tutorial, we'll show you how to enable user authentication in the LocalLibrary website, create your own login and logout pages, add permissions to your models, and control access to pages.We'll use the authentication / permissions to display lists of books that have been borrowed for both users and librarians. 90005 90002 The authentication system is very flexible, and you can build up your URLs, forms, views, and templates from scratch if you like, just calling the provided API to log in the user. However, in this article, we're going to use Django's "stock" authentication views and forms for our login and logout pages. We'll still need to create some templates, but that's pretty easy.90005 90002 We'll also show you how to create permissions, and check on login status and permissions in both views and templates. 90005 90006 Enabling authentication 90007 90002 The authentication was enabled automatically when we created the skeleton website (in tutorial 2) so you do not need to do anything more at this point. 90005 90002 90015 Note 90016: The necessary configuration was all done for us when we created the app using the 90009 django-admin startproject 90010 command.The database tables for users and model permissions were created when we first called 90009 python manage.py migrate 90010. 90005 90002 The configuration is set up in the 90009 INSTALLED_APPS 90010 and 90009 MIDDLEWARE 90010 sections of the project file (90015 locallibrary / locallibrary / settings.py 90016), as shown below: 90005 90044 INSTALLED_APPS = [ ... 90015 'django.contrib.auth', 90016 #Core authentication framework and its default models. 90015 'django.contrib.contenttypes ', # 90016 Django content type system (allows permissions to be associated with models). .... MIDDLEWARE = ​​[ ... 90015 'django.contrib.sessions.middleware.SessionMiddleware', 90016 #Manages sessions across requests ... 90015 'django.contrib.auth.middleware.AuthenticationMiddleware', 90016 #Associates users with requests using sessions. .... 90053 90006 Creating users and groups 90007 90002 You already created your first user when we looked at the Django admin site in tutorial 4 (this was a superuser, created with the command 90009 python manage.py createsuperuser) 90010. Our superuser is already authenticated and has all permissions, so we'll need to create a test user to represent a normal site user. We'll be using the admin site to create our 90003 locallibrary 90004 groups and website logins, as it is one of the quickest ways to do so. 90005 90002 Note: You can also create users programmatically, as shown below. You would have to do this, for example, if developing an interface to allow users to create their own logins (you should not give users access to the admin site).90005 90044 from django.contrib.auth.models import User # Create user and save to the database user = User.objects.create_user ( 'myusername', '[email protected]', 'mypassword') # Update fields and then save again user.first_name = 'John' user.last_name = 'Citizen' user.save () 90053 90002 Below we'll first create a group and then a user. Even though we do not have any permissions to add for our library members yet, if we need to later, it will be much easier to add them once to the group than individually to each member.90005 90002 Start the development server and navigate to the admin site in your local web browser (http://127.0.0.1:8000/admin/). Login to the site using the credentials for your superuser account. The top level of the Admin site displays all of your models, sorted by "Django application". From the 90015 Authentication and Authorisation 90016 section, you can click the 90015 Users 90016 or 90015 Groups 90016 links to see their existing records. 90005 90002 90005 90002 First lets create a new group for our library members.90005 90080 90081 Click the 90015 Add 90016 button (next to Group) to create a new 90003 Group 90004; enter the 90015 Name 90016 "Library Members" for the group. 90088 90081 We do not need any permissions for the group, so just press 90015 SAVE 90016 (you will be taken to a list of groups). 90088 90093 90002 Now let's create a user: 90005 90080 90081 Navigate back to the home page of the admin site 90088 90081 Click the 90015 Add 90016 button next to 90003 Users 90004 to open the 90003 Add user 90004 dialogue.90088 90081 Enter an appropriate 90015 Username 90016 and 90015 Password 90016/90015 Password confirmation 90016 for your test user 90088 90081 Press 90015 SAVE 90016 to create the user. 90002 The admin site will create the new user and immediately take you to a 90003 Change user 90004 screen where you can change your 90015 username 90016 and add information for the User model's optional fields. These fields include the first name, last name, email address, and the user's status and permissions (only the 90015 Active 90016 flag should be set).Further down you can specify the user's groups and permissions, and see important dates related to the user (e.g. their join date and last login date). 90005 90088 90081 In the 90003 Groups 90004 section, select 90015 Library Member 90016 group from the list of 90003 Available groups 90004, and then press the 90015 right-arrow 90016 between the boxes to move it into the 90003 Chosen groups 90004 box. 90088 90081 We do not need to do anything else here, so just select 90015 SAVE 90016 again, to go to the list of users.90088 90093 90002 That's it! Now you have a "normal library member" account that you will be able to use for testing (once we've implemented the pages to enable them to log in). 90005 90002 90015 Note 90016: You should try creating another library member user. Also, create a group for Librarians, and add a user to that too! 90005 90006 Setting up your authentication views 90007 90002 Django provides almost everything you need to create authentication pages to handle login, log out, and password management "out of the box".This includes a URL mapper, views and forms, but it does not include the templates - we have to create our own! 90005 90002 In this section, we show how to integrate the default system into the 90003 LocalLibrary 90004 website and create the templates. We'll put them in the main project URLs. 90005 90002 90015 Note 90016: You do not have to use any of this code, but it is likely that you'll want to because it makes things a lot easier. You'll almost certainly need to change the form handling code if you change your user model (an advanced topic!) But even so, you would still be able to use the stock view functions.90005 90002 90015 Note: 90016 In this case, we could reasonably put the authentication pages, including the URLs and templates, inside our catalog application. However, if we had multiple applications it would be better to separate out this shared login behaviour and have it available across the whole site, so that is what we've shown here! 90005 90166 Project URLs 90167 90002 Add the following to the bottom of the project urls.py file (90015 locallibrary / locallibrary / urls.py 90016) file: 90005 90044 #Add Django site authentication urls (for login, logout, password management) urlpatterns + = [ path ( 'accounts /', include ( 'django.contrib.auth.urls ')), ] 90053 90002 Navigate to the http://127.0.0.1:8000/accounts/ URL (note the trailing forward slash!) And Django will show an error that it could not find this URL, and listing all the URLs it tried. From this you can see the URLs that will work, for example: 90005 90002 90015 Note: 90016 Using the above method adds the following URLs with names in square brackets, which can be used to reverse the URL mappings. You do not have to implement anything else - the above URL mapping automatically maps the below mentioned URLs.90005 90044 accounts / login / [name = 'login'] accounts / logout / [name = 'logout'] accounts / password_change / [name = 'password_change'] accounts / password_change / done / [name = 'password_change_done'] accounts / password_reset / [name = 'password_reset'] accounts / password_reset / done / [name = 'password_reset_done'] accounts / reset / / / [name = 'password_reset_confirm'] accounts / reset / done / [name = 'password_reset_complete'] 90053 90002 Now try to navigate to the login URL (http: // 127.0.0.1: 8000 / accounts / login /). This will fail again, but with an error that tells you that we're missing the required template (90015 registration / login.html 90016) on the template search path. You'll see the following lines listed in the yellow section at the top: 90005 90044 Exception Type: TemplateDoesNotExist Exception Value: 90015 registration / login.html 90016 90053 90002 The next step is to create a registration directory on the search path and then add the 90015 login.html 90016 file.90005 90166 Template directory 90167 90002 The URLs (and implicitly, views) that we just added expect to find their associated templates in a directory 90015 / registration / 90016 somewhere in the templates search path. 90005 90002 For this site, we'll put our HTML pages in the 90015 templates / registration / 90016 directory. This directory should be in your project root directory, i.e the same directory as the 90015 catalog 90016 and 90015 locallibrary 90016 folders). Please create these folders now.90005 90002 90015 Note: 90016 Your folder structure should now look like the below: 90211 locallibrary (Django project folder) 90211 | _catalog 90211 | _locallibrary 90211 | _templates 90015 (new) 90016 90211 | _registration 90005 90002 To make these directories visible to the template loader (ie to put this directory in the template search path) open the project settings (90015 /locallibrary/locallibrary/settings.py 90016), and update the 90009 TEMPLATES 90010 section's 90009 'DIRS' 90010 line as shown.90005 90044 TEMPLATES = [ { ... 90015 'DIRS': [os.path.join (BASE_DIR, 'templates')], 90016 'APP_DIRS': True, ... 90053 90166 Login template 90167 90002 90015 Important 90016: The authentication templates provided in this article are a very basic / slightly modified version of the Django demonstration login templates. You may need to customise them for your own use! 90005 90002 Create a new HTML file called / 90015 locallibrary / templates / registration / login.html 90016 and give it the following contents: 90005 90044 {% extends "base_generic.html"%} {% Block content%} {% If form.errors%}

Your username and password did not match. Please try again. {% Endif%} {% If next%} {% If user.is_authenticated%}

Your account does not have access to this page. To proceed, please login with an account that has access. {% Else%}

Please login to see this page. {% Endif%} {% Endif%}

{% Csrf_token%}
{{form.username.label_tag}} {{form.username}}
{{form.password.label_tag}} {{form.password}} {# Assumes you setup the password_reset view in your URLconf #}

Lost password? {% Endblock%} 90053 90002 This template shares some similarities with the ones we've seen before - it extends our base template and overrides the 90009 content 90010 block.The rest of the code is fairly standard form handling code, which we will discuss in a later tutorial. All you need to know for now is that this will display a form in which you can enter your username and password, and that if you enter invalid values ​​you will be prompted to enter correct values ​​when the page refreshes. 90005 90002 Navigate back to the login page (http://127.0.0.1:8000/accounts/login/) once you've saved your template, and you should see something like this: 90005 90002 90005 90002 If you log in using valid credentials, you'll be redirected to another page (by default this will be http: // 127.0.0.1: 8000 / accounts / profile /). The problem is that, by default, Django expects that upon logging in you will want to be taken to a profile page, which may or may not be the case. As you have not defined this page yet, you'll get another error! 90005 90002 Open the project settings (90015 /locallibrary/locallibrary/settings.py 90016) and add the text below to the bottom. Now when you log in you should be redirected to the site homepage by default. 90005 90044 # Redirect to home URL after login (Default redirects to / accounts / profile /) LOGIN_REDIRECT_URL = '/' 90053 90166 Logout template 90167 90002 If you navigate to the logout URL (http: // 127.0.0.1: 8000 / accounts / logout /) then you'll see some odd behaviour - your user will be logged out sure enough, but you'll be taken to the 90015 Admin 90016 logout page. That's not what you want, if only because the login link on that page takes you to the Admin login screen (and that is only available to users who have the 90009 is_staff 90010 permission). 90005 90002 Create and open / 90015 locallibrary / templates / registration / logged_out.html 90016. Copy in the text below: 90005 90044 {% extends "base_generic.html "%} {% Block content%}

Logged out! Click here to login again. {% Endblock%} 90053 90002 This template is very simple. It just displays a message informing you that you have been logged out, and provides a link that you can press to go back to the login screen. If you go to the logout URL again you should see this page: 90005 90002 90005 90166 Password reset templates 90167 90002 The default password reset system uses email to send the user a reset link.You need to create forms to get the user's email address, send the email, allow them to enter a new password, and to note when the whole process is complete. 90005 90002 The following templates can be used as a starting point. 90005 90283 Password reset form 90284 90002 This is the form used to get the user's email address (for sending the password reset email). Create 90015 /locallibrary/templates/registration/password_reset_form.html 90016, and give it the following contents: 90005 90044 {% extends "base_generic.html "%} {% Block content%} {% Csrf_token%} {% If form.email.errors%} {{Form.email.errors}} {% Endif%}

{{form.email}} {% Endblock%} 90053 90283 Password reset done 90284 90002 This form is displayed after your email address has been collected. Create 90015 /locallibrary/templates/registration/password_reset_done.html 90016, and give it the following contents: 90005 90044 {% extends "base_generic.html "%} {% Block content%}

We've emailed you instructions for setting your password. If they have not arrived in a few minutes, check your spam folder. {% Endblock%} 90053 90283 Password reset email 90284 90002 This template provides the text of the HTML email containing the reset link that we will send to users. Create 90015 /locallibrary/templates/registration/password_reset_email.html 90016, and give it the following contents: 90005 90044 Someone asked for password reset for email {{email}}.Follow the link below: {{Protocol}}: // {{domain}} {% url 'password_reset_confirm' uidb64 = uid token = token%} 90053 90283 Password reset confirm 90284 90002 This page is where you enter your new password after clicking the link in the password reset email. Create 90015 /locallibrary/templates/registration/password_reset_confirm.html 90016, and give it the following contents: 90005 90044 {% extends "base_generic.html"%} {% Block content%} {% If validlink%}

Please enter (and confirm) your new password. {% Csrf_token%}

{{form.new_password1.errors}} {{form.new_password1}}
{{form.new_password2.errors}} {{form.new_password2}}
{% Else%}

Password reset failed

The password reset link was invalid, possibly because it has already been used. Please request a new password reset. {% Endif%} {% Endblock%} 90053 90283 Password reset complete 90284 90002 This is the last password-reset template, which is displayed to notify you when the password reset has succeeded.Create 90015 /locallibrary/templates/registration/password_reset_complete.html 90016, and give it the following contents: 90005 90044 {% extends "base_generic.html"%} {% Block content%}

The password has been changed!

log in again? {% Endblock%} 90053 90166 Testing the new authentication pages 90167 90002 Now that you've added the URL configuration and created all these templates, the authentication pages should now just work! 90005 90002 You can test the new authentication pages by attempting to log in to and then log out of your superuser account using these URLs: 90005 90002 You'll be able to test the password reset functionality from the link in the login page.90015 Be aware that Django will only send reset emails to addresses (users) that are already stored in its database! 90016 90005 90002 90015 Note 90016: The password reset system requires that your website supports email, which is beyond the scope of this article, so this part 90015 will not work yet 90016. To allow testing, put the following line at the end of your settings.py file. This logs any emails sent to the console (so you can copy the password reset link from the console). 90005 90044 EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend ' 90053 90002 For more information, see Sending email (Django docs). 90005 90006 Testing against authenticated users 90007 90002 This section looks at what we can do to selectively control content the user sees based on whether they are logged in or not. 90005 90166 Testing in templates 90167 90002 You can get information about the currently logged in user in templates with the 90009 {{user}} 90010 template variable (this is added to the template context by default when you set up the project as we did in our skeleton).90005 90002 Typically you will first test against the 90009 {{user.is_authenticated}} 90010 template variable to determine whether the user is eligible to see specific content. To demonstrate this, next we'll update our sidebar to display a "Login" link if the user is logged out, and a "Logout" link if they are logged in. 90005 90002 Open the base template (90015 /locallibrary/catalog/templates/base_generic.html 90016) and copy the following text into the 90009 sidebar 90010 block, immediately before the 90009 endblock 90010 template tag.90005 90044

    ... 90015 {% if user.is_authenticated%} 90016
  • User: 90015 {{user.get_username}} 90016
  • Logout 90015 {% else%} 90016
  • Login 90015 {% endif%} 90016 90053 90002 As you can see, we use 90009 if 90010 - 90009 else 90010 - 90009 endif 90010 template tags to conditionally display text based on whether 90009 {{user.is_authenticated}} 90010 is true. If the user is authenticated then we know that we have a valid user, so we call 90009 {{user.get_username}} 90010 90015 90016 to display their name. 90005 90002 We create the login and logout link URLs using the 90009 url 90010 template tag and the names of the respective URL configurations. Note also how we have appended 90009? Next = {{request.path}} 90010 to the end of the URLs. What this does is add a URL parameter next containing the address (URL) of the 90003 current 90004 page, to the end of the linked URL.After the user has successfully logged in / out, the views will use this "90009 next 90010" value to redirect the user back to the page where they first clicked the login / logout link. 90005 90002 90015 Note 90016: Try it out! If you're on the home page and you click Login / Logout in the sidebar, then after the operation completes you should end up back on the same page. 90005 90166 Testing in views 90167 90002 If you're using function-based views, the easiest way to restrict access to your functions is to apply the 90009 login_required 90010 decorator to your view function, as shown below.If the user is logged in then your view code will execute as normal. If the user is not logged in, this will redirect to the login URL defined in the project settings (90009 settings.LOGIN_URL 90010), passing the current absolute path as the 90009 next 90010 URL parameter. If the user succeeds in logging in then they will be returned back to this page, but this time authenticated. 90005 90044 from django.contrib.auth.decorators import login_required @login_required def my_view (request): ... 90053 90002 90015 Note: 90016 You can do the same sort of thing manually by testing on 90009 request.user.is_authenticated 90010, but the decorator is much more convenient! 90005 90002 Similarly, the easiest way to restrict access to logged-in users in your class-based views is to derive from 90009 LoginRequiredMixin 90010. You need to declare this mixin first in the superclass list, before the main view class. 90005 90044 from django.contrib.auth.mixins import LoginRequiredMixin class MyView (LoginRequiredMixin, View): ... 90053 90002 This has exactly the same redirect behaviour as the 90009 login_required 90010 decorator. You can also specify an alternative location to redirect the user to if they are not authenticated (90009 login_url 90010), and a URL parameter name instead of "90009 next 90010" to insert the current absolute path (90009 redirect_field_name 90010). 90005 90044 class MyView (LoginRequiredMixin, View): login_url = '/ login /' redirect_field_name = 'redirect_to' 90053 90002 For additional detail, check out the Django docs here.90005 90006 Example - listing the current user's books 90007 90002 Now that we know how to restrict a page to a particular user, let's create a view of the books that the current user has borrowed. 90005 90002 Unfortunately, we do not yet have any way for users to borrow books! So before we can create the book list we'll first extend the 90009 BookInstance 90010 model to support the concept of borrowing and use the Django Admin application to loan a number of books to our test user. 90005 90166 Models 90167 90002 First, we're going to have to make it possible for users to have a 90009 BookInstance 90010 on loan (we already have a 90009 status 90010 and a 90009 due_back 90010 date, but we do not yet have any association between this model and a User.We'll create one using a 90009 ForeignKey 90010 (one-to-many) field. We also need an easy mechanism to test whether a loaned book is overdue. 90005 90002 Open 90015 catalog / models.py 90016, and import the 90009 User 90010 model from 90009 django.contrib.auth.models 90010 (add this just below the previous import line at the top of the file, so 90009 User 90010 is available to subsequent code that makes use of it): 90005 90044 from django.contrib.auth.models import User 90053 90002 Next, add the 90009 borrower 90010 field to the 90009 BookInstance 90010 model: 90005 90044 borrower = models.ForeignKey (User, on_delete = models.SET_NULL, null = True, blank = True) 90053 90002 While we're here, let's add a property that we can call from our templates to tell if a particular book instance is overdue. While we could calculate this in the template itself, using a property as shown below will be much more efficient. 90005 90002 Add this somewhere near the top of the file: 90005 90044 from datetime import date 90053 90002 Now add the following property definition to the 90009 BookInstance 90010 class: 90005 90044 @property def is_overdue (self): if self.due_back and date.today ()> self.due_back: return True return False 90053 90002 90015 Note 90016: We first verify whether 90009 due_back 90010 is empty before making a comparison. An empty 90009 due_back 90010 field would cause Django to throw an error instead of showing the page: empty values ​​are not comparable. This is not something we would want our users to experience! 90005 90002 Now that we've updated our models, we'll need to make fresh migrations on the project and then apply those migrations: 90005 90044 python3 manage.py makemigrations python3 manage.py migrate 90053 90166 Admin 90167 90002 Now open 90015 catalog / admin.py 90016, and add the 90009 borrower 90010 field to the 90009 BookInstanceAdmin 90010 class in both the 90009 list_display 90010 and the 90009 fieldsets 90010 as shown below. This will make the field visible in the Admin section, allowing us to assign a 90009 User 90010 to a 90009 BookInstance 90010 when needed. 90005 90044 @ admin.register (BookInstance) class BookInstanceAdmin (admin.ModelAdmin): list_display = ( 'book', 'status' 90015, 'borrower' 90016, 'due_back', 'id') list_filter = ( 'status', 'due_back') fieldsets = ( (None, { 'Fields': ( 'book', 'imprint', 'id') }), ( 'Availability', { 'Fields': ( 'status', 'due_back' 90015, 'borrower' 90016) }), ) 90053 90166 Loan a few books 90167 90002 Now that it's possible to loan books to a specific user, go and loan out a number of 90009 BookInstance 90010 records.Set their 90009 borrowed 90010 field to your test user, make the 90009 status 90010 "On loan", and set due dates both in the future and the past. 90005 90002 90015 Note 90016: We will not spell the process out, as you already know how to use the Admin site! 90005 90166 On loan view 90167 90002 Now we'll add a view for getting the list of all books that have been loaned to the current user. We'll use the same generic class-based list view we're familiar with, but this time we'll also import and derive from 90009 LoginRequiredMixin 90010, so that only a logged in user can call this view.We will also choose to declare a 90009 template_name 90010, rather than using the default, because we may end up having a few different lists of BookInstance records, with different views and templates. 90005 90002 Add the following to catalog / views.py: 90005 90044 from django.contrib.auth.mixins import LoginRequiredMixin class LoanedBooksByUserListView (LoginRequiredMixin, generic.ListView): "" "Generic class-based view listing books on loan to current user." "" model = BookInstance template_name = 'catalog / bookinstance_list_borrowed_user.html ' paginate_by = 10 def get_queryset (self): return BookInstance.objects.filter (borrower = self.request.user) .filter (status__exact = 'o'). order_by ( 'due_back') 90053 90002 In order to restrict our query to just the 90009 BookInstance 90010 objects for the current user, we re-implement 90009 get_queryset () 90010 as shown above. Note that "o" is the stored code for "on loan" and we order by the 90009 due_back 90010 date so that the oldest items are displayed first. 90005 90166 URL conf for on loan books 90167 90002 Now open 90015 / catalog / urls.py 90016 and add a 90009 path () 90010 pointing to the above view (you can just copy the text below to the end of the file). 90005 90044 urlpatterns + = [ path ( 'mybooks /', views.LoanedBooksByUserListView.as_view (), name = 'my-borrowed'), ] 90053 90166 Template for on-loan books 90167 90002 Now, all we need to do for this page is add a template. First, create the template file 90015 /catalog/templates/catalog/bookinstance_list_borrowed_user.html 90016 and give it the following contents: 90005 90044 {% extends "base_generic.html "%} {% Block content%}

    Borrowed books {% If bookinstance_list%}
      {% For bookinst in bookinstance_list%}
    • {{bookinst.book.title}} ({{bookinst.due_back}}) {% Endfor%} {% Else%}

      There are no books borrowed. {% Endif%} {% Endblock%} 90053 90002 This template is very similar to those we've created previously for the 90009 Book 90010 and 90009 Author 90010 objects.The only thing "new" here is that we check the method we added in the model 90009 (bookinst.is_overdue 90010) and use it to change the colour of overdue items. 90005 90002 When the development server is running, you should now be able to view the list for a logged in user in your browser at http://127.0.0.1:8000/catalog/mybooks/. Try this out with your user logged in and logged out (in the second case, you should be redirected to the login page). 90005 90002 The very last step is to add a link for this new page into the sidebar.We'll put this in the same section where we display other information for the logged in user. 90005 90002 Open the base template (90015 /locallibrary/catalog/templates/base_generic.html 90016) and add the line in bold to the sidebar as shown. 90005 90044

        {% If user.is_authenticated%}
      • User: {{user.get_username}} 90015
      • My Borrowed 90016
      • Logout {% Else%}
      • Login {% Endif%} 90053 90166 What does it look like? 90167 90002 When any user is logged in, they'll see the 90003 My Borrowed 90004 link in the sidebar, and the list of books displayed as below (the first book has no due date, which is a bug we hope to fix in a later tutorial!). 90005 90002 90005 90006 Permissions 90007 90002 Permissions are associated with models and define the operations that can be performed on a model instance by a user who has the permission.By default, Django automatically gives 90003 add 90004, 90003 change 90004, and 90003 delete 90004 permissions to all models, which allow users with the permissions to perform the associated actions via the admin site. You can define your own permissions to models and grant them to specific users. You can also change the permissions associated with different instances of the same model. 90005 90002 Testing on permissions in views and templates is then very similar for testing on the authentication status (and in fact, testing for a permission also tests for authentication).90005 90166 Models 90167 90002 Defining permissions is done on the model "90009 class Meta 90010" section, using the 90009 permissions 90010 field. You can specify as many permissions as you need in a tuple, each permission itself being defined in a nested tuple containing the permission name and permission display value. For example, we might define a permission to allow a user to mark that a book has been returned as shown: 90005 90044 class BookInstance (models.Model): ... class Meta: ... 90015 permissions = (( "can_mark_returned", "Set book as returned"),) 90016 90053 90002 We could then assign the permission to a "Librarian" group in the Admin site. 90005 90002 Open the 90015 catalog / models.py 90016, and add the permission as shown above. You will need to re-run your migrations (call 90009 python3 manage.py makemigrations 90010 and 90009 python3 manage.py migrate 90010) to update the database appropriately. 90005 90166 Templates 90167 90002 The current user's permissions are stored in a template variable called 90009 {{perms}} 90010.You can check whether the current user has a particular permission using the specific variable name within the associated Django "app" - e.g. 90009 {{perms.catalog.can_mark_returned}} 90010 will be 90009 True 90010 if the user has this permission, and 90009 False 90010 otherwise. We typically test for the permission using the template 90009 {% if%} 90010 tag as shown: 90005 90044 {% if perms.catalog.can_mark_returned%} {% Endif%} 90053 90166 Views 90167 90002 Permissions can be tested in function view using the 90009 permission_required 90010 decorator or in a class-based view using the 90009 PermissionRequiredMixin 90010. The pattern and behaviour are the same as for login authentication, though of course, you might reasonably have to add multiple permissions. 90005 90002 Function view decorator: 90005 90044 from django.contrib.auth.decorators import permission_required @permission_required ( 'catalog.can_mark_returned ') @permission_required ( 'catalog.can_edit') def my_view (request): ... 90053 90002 A permission-required mixin for class-based views. 90005 90044 from django.contrib.auth.mixins import PermissionRequiredMixin class MyView (PermissionRequiredMixin, View): permission_required = 'catalog.can_mark_returned' # Or multiple permissions permission_required = ( 'catalog.can_mark_returned', 'catalog.can_edit') # Note that 'catalog.can_edit' is just an example # The catalog application does not have such permission! 90053 90166 Example 90167 90002 We will not update the 90003 LocalLibrary 90004 here; perhaps in the next tutorial! 90005 90006 Challenge yourself 90007 90002 Earlier in this article, we showed you how to create a page for the current user listing the books that they have borrowed.The challenge now is to create a similar page that is only visible for librarians, that displays 90003 all 90004 books that have been borrowed, and which includes the name of each borrower. 90005 90002 You should be able to follow the same pattern as for the other view. The main difference is that you'll need to restrict the view to only librarians. You could do this based on whether the user is a staff member (function decorator: 90009 staff_member_required 90010, template variable: 90009 user.is_staff 90010) but we recommend that you instead use the 90009 can_mark_returned 90010 permission and 90009 PermissionRequiredMixin 90010, as described in the previous section. 90005 90002 90015 Important 90016: Remember not to use your superuser for permissions based testing (permission checks always return true for superusers, even if a permission has not yet been defined!). Instead, create a librarian user, and add the required capability. 90005 90002 When you are finished, your page should look something like the screenshot below.90005 90002 90005 90006 Summary 90007 90002 Excellent work - you've now created a website that library members can log in into and view their own content and that librarians (with the correct permission) can use to view all loaned books and their borrowers. At the moment we're still just viewing content, but the same principles and techniques are used when you want to start modifying and adding data. 90005 90002 In our next article, we'll look at how you can use Django forms to collect user input, and then start modifying some of our stored data.90005 90006 See also 90007 90006 In this module 90007 .90000 HTTP authentication - Web technology for developers 90001 90002 HTTP provides a general framework for access control and authentication. This page is an introduction to the HTTP framework for authentication, and shows how to restrict access to your server using the HTTP "Basic" schema. 90003 90004 The general HTTP authentication framework 90005 90002 RFC 7235 defines the HTTP authentication framework, which can be used by a server to challenge a client request, and by a client to provide authentication information.90003 90002 The challenge and response flow works like this: 90003 90010 90011 The server responds to a client with a 90012 401 90013 (Unauthorized) response status and provides information on how to authorize with a 90012 WWW-Authenticate 90013 response header containing at least one challenge. 90016 90011 A client that wants to authenticate itself with the server can then do so by including an 90012 Authorization 90013 request header with the credentials. 90016 90011 Usually a client will present a password prompt to the user and will then issue the request including the correct 90012 Authorization 90013 header.90016 90025 90002 90003 90002 In the case of a "Basic" authentication like shown in the figure, the exchange 90029 must 90030 happen over an HTTPS (TLS) connection to be secure. 90003 90032 Proxy authentication 90033 90002 The same challenge and response mechanism can be used for 90035 proxy authentication 90036. As both resource authentication and proxy authentication can coexist, a different set of headers and status codes is needed. In the case of proxies, the challenging status code is 90012 407 90013 (Proxy Authentication Required), the 90012 Proxy-Authenticate 90013 response header contains at least one challenge applicable to the proxy, and the 90012 Proxy-Authorization 90013 request header is used for providing the credentials to the proxy server.90003 90032 Access forbidden 90033 90002 If a (proxy) server receives valid credentials that are inadequate to access a given resource, the server should respond with the 90012 403 90013 90012 Forbidden 90013 status code. Unlike 90012 401 90013 90012 Unauthorized 90013 or 90012 407 90013 90012 Proxy Authentication Required 90013, authentication is impossible for this user. 90003 90032 Authentication of cross-origin images 90033 90002 A potential security hole recently been fixed by browsers is authentication of cross-site images.From Firefox 59 onwards, image resources loaded from different origins to the current document are no longer able to trigger HTTP authentication dialogs (bug 1423146), preventing user credentials being stolen if attackers were able to embed an arbitrary image into a third-party page. 90003 90032 Character encoding of HTTP authentication 90033 90002 Browsers use 90012 utf-8 90013 encoding for usernames and passwords. 90003 90002 Firefox once used 90012 ISO-8859-1 90013, but changed to 90012 utf-8 90013 for parity with other browsers and to avoid potential problems as described in bug 1419658.90003 90032 WWW-Authenticate and Proxy-Authenticate headers 90033 90002 The 90012 WWW-Authenticate 90013 and 90012 Proxy-Authenticate 90013 response headers define the authentication method that should be used to gain access to a resource. They must specify which authentication scheme is used, so that the client that wishes to authorize knows how to provide the credentials. 90003 90002 The syntax for these headers is the following: 90003 90086 WWW-Authenticate: realm = Proxy-Authenticate: realm = 90087 90002 Here, 90012 90013 is the authentication scheme ( "Basic" is the most common scheme and introduced below).The 90035 realm 90036 is used to describe the protected area or to indicate the scope of protection. This could be a message like "Access to the staging site" or similar, so that the user knows to which space they are trying to get access to. 90003 90032 Authorization and Proxy-Authorization headers 90033 90002 The 90012 Authorization 90013 and 90012 Proxy-Authorization 90013 request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the 90012 90013 is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.90003 90086 Authorization: Proxy-Authorization: 90087 90032 Authentication schemes 90033 90002 The general HTTP authentication framework is used by several authentication schemes. Schemes can differ in security strength and in their availability in client or server software. 90003 90002 The most common authentication scheme is the "Basic" authentication scheme, which is introduced in more detail below. IANA maintains a list of authentication schemes, but there are other schemes offered by host services, such as Amazon AWS.Common authentication schemes include: 90003 90112 90113 90029 Basic 90030 90116 90117 See RFC 7617, base64-encoded credentials. More information below. 90118 90113 90029 Bearer 90030 90116 90117 See RFC 6750, bearer tokens to access OAuth 2.0-protected resources 90118 90113 90029 Digest 90030 90116 90117 See RFC 7616, only md5 hashing is supported in Firefox, see bug 472823 for SHA encryption support 90118 90113 90029 HOBA 90030 90116 90117 See RFC 7486, Section 3, 90029 H 90030 TTP 90029 O 90030 rigin- 90029 B 90030 ound 90029 A 90030 uthentication, digital-signature-based 90118 90113 90029 Mutual 90030 90116 90117 See RFC 8120 90118 90113 90029 AWS4-HMAC-SHA256 90030 90116 90117 See AWS docs 90118 90157 90004 Basic authentication scheme 90005 90002 The "Basic" HTTP authentication scheme is defined in RFC 7617, which transmits credentials as user ID / password pairs, encoded using base64.90003 90032 Security of basic authentication 90033 90002 As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme 90029 is not secure 90030. HTTPS / TLS should be used with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information. 90003 90032 Restricting access with Apache and basic authentication 90033 90002 To password-protect a directory on an Apache server, you will need a 90012.htaccess 90013 and a 90012 .htpasswd 90013 file. 90003 90002 The 90012 .htaccess 90013 file typically looks like this: 90003 90086 AuthType Basic AuthName "Access to the staging site" AuthUserFile /path/to/.htpasswd Require valid-user 90087 90002 The 90012 .htaccess 90013 file references a 90012 .htpasswd 90013 file in which each line consists of a username and a password separated by a colon (90012: 90013). You can not see the actual passwords as they are encrypted (md5 in this case).Note that you can name your 90012 .htpasswd 90013 file differently if you like, but keep in mind this file should not be accessible to anyone. (Apache is usually configured to prevent access to 90012 .ht * 90013 files). 90003 90086 aladdin: $ apr1 $ ZjTqBB3f $ IF9gdYAGlMrs2fuINjHsz. user2: $ apr1 $ O04r.y2H $ / vEkesPhVInBByJUkXitA / 90087 90032 Restricting access with nginx and basic authentication 90033 90002 For nginx, you will need to specify a location that you are going to protect and the 90012 auth_basic 90013 directive that provides the name to the password-protected area.The 90012 auth_basic_user_file 90013 directive then points to a 90012 .htpasswd 90013 file containing the encrypted user credentials, just like in the Apache example above. 90003 90086 location / status { auth_basic "Access to the staging site"; auth_basic_user_file /etc/apache2/.htpasswd; } 90087 90032 Access using credentials in the URL 90033 90002 Many clients also let you avoid the login prompt by using an encoded URL containing the username and the password like this: 90003 90086 https: // username: password @ www.example.com/ 90087 90002 90029 The use of these URLs is deprecated 90030. In Chrome, the 90012 username: password @ 90013 part in URLs is even stripped out for security reasons. In Firefox, it is checked if the site actually requires authentication and if not, Firefox will warn the user with a prompt "You are about to log in to the site" www.example.com "with the username" username ", but the website does not require authentication. This may be an attempt to trick you. " 90003 90004 See also 90005 .

        Отправить ответ

        avatar
          Подписаться  
        Уведомление о