4. usergate getting started. работа с пользователями

Введение

В условиях пандемии заболевания, вызванного новым коронавирусом (COVID-19), многие компании рассматривают отправку работников на «удалёнку», а некоторые уже активно внедряют такой режим работы. Это заставляет компании решать целый спектр вопросов, связанных с информационной безопасностью, так как ожидается, что число утечек информации и случаев несанкционированного доступа к корпоративным ресурсам значительно увеличится. Какие же основные проблемы удалённой работы с точки зрения ИБ стоят перед компаниями?

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

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

Что такое оauth2.0?


Разработку нового Auth мы решили начать с изучения доступных протоколов и технологий. Самый распространённый стандарт авторизации — фреймворк авторизации OAuth2.0. 

Стандарт был принят в 2022 году, и за 8 лет протокол меняли и дополняли. RFC стало настолько много, что авторы оригинального протокола решили написать OAuth 2.1, который объединит все текущие изменения по OAuth 2.0 в одном документе. Пока он на стадии черновика.

Актуальная версия OAuth описанна в RFC 6749. Именно его мы и разберем. 

OAuth 2.0 — это фреймворк авторизации.

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

Похожее:  Личный кабинет Эвотора: правила регистрации, инструкции по авторизации и использования

Особенности:

Разберёмся подробнее в особенностях.

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

Процитируем Википедию:

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

идентифицирован

 (мы должны знать, кто он) и

аутентифицирован

 (подтверждена его идентичность).

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

3.2. Авторизация пользователей

Платформа поддерживает различные механизмы авторизации пользователей: Captive-портал, Kerberos, NTLM, при этом учетные записи могут поступать из различных источников – LDAP, Active directory, FreeIPA, TACACS , Radius, SAML IDP. Авторизация SAML IDP, Kerberos или NTLM позволяет прозрачно (без запроса имени пользователя и его пароля) авторизовать пользователей домена Active Directory.

Администратор может настроить правила безопасности, ширину канала, правила межсетевого экранирования, контентной фильтрации и контроля приложений для отдельных пользователей, групп пользователей, а также всех известных или неизвестных пользователей. Дополнительно к этому продукт поддерживает применение правил безопасности к пользователям терминальных служб с помощью специальных агентов (Terminal Services Agents), а также использование агента авторизации для Windows-платформ.

Для обеспечения большей безопасности учетных записей рекомендуется использовать мультифакторную аутентификацию с помощью токенов TOTP (Time-based One Time Password Algorithm), SMS или электронной почты.

Авторизация¶

2.1. Авторизация с помощью Kerberos

Авторизация Kerberos позволяет прозрачно (без запроса имени пользователя и его пароля) авторизовать пользователей домена Active Directory. При авторизации через Kerberos сервер UserGate работает с контроллерами домена, которые выполняют проверку пользователя, который получает доступ в интернет.

  1. Создадим DNS записи для сервера UserGate. Необходимо создавать записи типа A, не создавайте записи типа CNAME.

image12

Где 10.1.10.21 IP адрес интерфейса UserGate подключенного в зону Trusted.

  1. Создадим пользователя в домене AD, например kerb@kraftec.net с опцией password never expires (срок действия пароля не ограничен). Установим пароль пользователю kerb.

  1. Создадим keytab файл на контроллере домена. Выполним следующую команду из-под администратора (команда в одну строку!):

ktpass.exe /princ HTTP/auth.kraftec.net@KRAFTEC.NET /mapuser kerb@KRAFTEC.NET /crypto ALL /ptype krb5_NT_PRINCIPAL /pass * /out C:utm.keytab

Введем пароль пользователя kerb.

image13

auth.kraftec.net — DNS — запись, созданная для сервера UserGate в пункте 1.

KRAFTEC.NET — Kerberos realm domain, обязательно большими буквами.

kerb@KRAFTEC.NET — имя пользователя в домене, созданное в пункте 2, имя realm-домена обязательно большими буквами.

  1. В разделе DNS — Системные DNS серверы укажем IP-адреса контроллеров домена.

  2. Настроим синхронизацию времени с контроллером домена.

В разделе НастройкиНастройка времени сервера, установим Основной NTP-сервер — IP адрес контроллера домена. В качестве запасного — опционально — укажем IP адрес другого контроллера домена.

image14

  1. Изменим адрес домена Auth Captive-портала.

В разделе Настройки →Модули, изменим названия Доменов на созданные доменные имена в пункте 1.

image15

  1. Создадим LDAP – коннектор для получения информации о пользователях и группах Active Directory и загрузим в него keytab – файл.

Перейдем в раздел Пользователи и устройства → Серверы авторизации, нажмем кнопку Добавить → Добавить LDAP коннектор.

В свойствах коннектора LDAP внесем следующие настройки:

Вкладка Настройки

Название: произвольное название LDAP – коннектора.

Доменное имя LDAP или IP-адрес: IP-адрес сервера контроллера домена.

Bind DN («логин»): внесем доменного пользователя в формате DOMAINusername или username@domain для подключения к серверу LDAP. Данный пользователь уже должен быть заведен в домене.

Пароль: пароль пользователя для подключения к домену.

image16

Вкладка Домены LDAP

Нажмем кнопку Добавить и внесем доменное имя LDAP

image17

Вкладка Домены LDAP

Нажмем кнопку Загрузить keytab файл и выберем файл, созданный в пункте 3.

image18

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

image19

Сохраним настройки LDAP коннектора нажав на кнопку Сохранить.

  1. Создадим профиль авторизации для Kerberos.

В разделе Пользователи и устройства → Профили авторизации, нажмем кнопку Добавить.

Вкладке Общие.

Название: произвольное название профиля авторизации.

image20

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

Нажмем кнопку Добавить и выберем Аутентификация Kerberos.

image21

Сохраним настройки профиля авторизации нажав на кнопку Сохранить.

  1. Создадим Captive-профиль.

В разделе Пользователи и устройства → Captive-профили, нажмем кнопку Добавить.

Вкладка Общие

Название: произвольное название captive — профиля.

Профиль авторизации: выберем ранее созданный профиль авторизации.

image22

Сохраним настройки Captive-профиля нажав на кнопку Сохранить.

  1. Создадим правило Captive-портала для авторизации Kerberos.

В разделе Пользователи и устройства → Captive-портал, нажмем кнопку Добавить.

Вкладка Общие

Название: произвольное название правила captive-портала.

Captive-профиль: выберем ранее созданный captive-профиль.

image23

Сохраним настройки правила Captive-портала нажав на кнопку Сохранить.

  1. Разрешить доступ к сервису HTTP(S) для зоны.

В разделе Зоны разрешить доступ к сервису HTTP(S)-прокси для зоны, к которой подключены пользователи, авторизующиеся с помощью Kerberos.

image24

  1. Произведем настройки на компьютере пользователя.

Настройка прокси-сервера для авторизации в стандартном режиме.

Панель управленияСвойства браузераПодключенияНастройка сетиПрокси-сервер и указать FQDN (полное имя) и порт интерфейса UserGate, к которому будут подключены пользователи.

image25

Настройка авторизации в прозрачном режиме.

Панель управления → Свойства браузера →безопасность → выберите зону Интернет → Уровень безопасности → Другой → Проверка подлинности пользователя и установите Автоматический вход в сеть с текущим именем пользователя и пароля.

image26

2.3. Авторизация с помощью NTLM

Авторизация NTLM позволяет прозрачно (без запроса имени пользователя и его пароля) авторизовать пользователей домена Active Directory. При авторизации с помощью NTLM сервер UserGate работает с контроллерами домена, которые выполняют проверку пользователя, который получает доступ в интернет.

  1. Создадим LDAP – коннектор для получения информации о пользователях и группах Active Directory.

Перейдем в раздел Пользователи и устройства → Серверы авторизации, нажмем кнопку Добавить → Добавить LDAP коннектор.

В свойствах коннектора LDAP внесем следующие настройки:

Вкладка Настройки

Название: произвольное название LDAP – коннектора.

Доменное имя LDAP или IP-адрес: IP-адрес сервера контроллера домена.

Bind DN («логин»): внесем доменного пользователя в формате DOMAINusername или username@domain для подключения к серверу LDAP. Данный пользователь уже должен быть заведен в домене.

Пароль: пароль пользователя для подключения к домену.

image27

Вкладка Домены LDAP

Нажмем кнопку Добавить и внесем доменное имя LDAP

image28

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

image29

Сохраним настройки LDAP коннектора нажав на кнопку Сохранить.

  1. Создадим NTLM — сервер авторизации.

В разделе Пользователи и устройства → Серверы авторизации, нажмем кнопку Добавить → Добавить NTLM-сервер.

Название: произвольное название сервера авторизации.

IP-адрес: IP адрес контроллера домена.

Домен Windows: доменное имя.

image30

Сохраним настройки NTLM сервера нажав на кнопку Сохранить.

  1. Создадим профиль авторизации для NTLM сервера.

В разделе Пользователи и устройства → Профили авторизации, нажмем кнопку Добавить.

Вкладке Общие.

Название: произвольное название профиля авторизации.

image31

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

image32

Нажмем кнопку Добавить и выберем ранее созданный NTLM сервер.

Сохраним настройки профиля авторизации нажав на кнопку Сохранить.

  1. Создадим Captive-профиль.

В разделе Пользователи и устройства → Captive-профили, нажмем кнопку Добавить.

Вкладка Общие

Название: произвольное название captive — профиля.

Профиль авторизации: выберем ранее созданный NTLM профиль.

image33

Сохраним настройки Captive-профиля нажав на кнопку Сохранить.

  1. Создадим правило Captive-портала для NTLM авторизации.

В разделе Пользователи и устройства → Captive-портал, нажмем кнопку Добавить.

Вкладка Общие

Название: произвольное название правила captive-портала.

image34

Captive-профиль: выберем ранее созданный captive-профиль.

Сохраним настройки правила Captive-портала нажав на кнопку Сохранить.

  1. Настроим синхронизацию времени с контроллером домена.

В разделе НастройкиНастройка времени сервера, установим Основной NTP-сервер — IP адрес контроллера домена.

image35

  1. Создадим DNS записи для сервера UserGate.

image36

Где 10.1.10.21 IP адрес интерфейса UserGate подключенного в зону Trusted.

  1. Изменим адрес домена Auth Captive-портала.

В разделе Настройки →Модули, изменим названия Доменов на созданные доменные имена в предыдущем разделе.

image37

  1. Разрешить доступ к сервису HTTP(S) для зоны.

В разделе Зоны разрешить доступ к сервису HTTP(S)-прокси для зоны, к которой подключены пользователи, авторизующиеся с помощью NTLM.

image38

  1. Произведем настройки на компьютере пользователя.

Настройка прокси-сервера для авторизации в стандартном режиме.

Панель управленияСвойства браузераПодключенияНастройка сетиПрокси-сервер и указать IP адрес и порт интерфейса UserGate, к которому будут подключены пользователи.

image39

Настройка авторизации в прозрачном режиме.

Панель управления → Свойства браузера →безопасность → выберите зону Интернет → Уровень безопасности → Другой → Проверка подлинности пользователя и установите Автоматический вход в сеть с текущим именем пользователя и пароля.

image40

Панель управления → Свойства браузера →Безопасность → установить. Разрешить встроенную проверку подлинности Windows.

image41

2.6. Настройка браузера Chrome на Linux для авторизации Kerberos/Captive portal

Для авторизации пользователей доменных компьютеров удобно использовать автоматическую авторизацию Kerberos. Для пользователей, чьи компьютеры не входят в домен, авторизация Kerberos работать не будет. Удобным вариантом в этом случае будет использование двух методов авторизации – в качестве первого метода авторизации Kerberos, а в качестве второго – Captive portal. На компьютерах с ОС Windows такой вариант работает хорошо, пользователям, не сумевшим пройти авторизацию Kerberos, будет предложено ввести авторизационные данные на странице Captive-портала. Для пользователей Linux с установленным браузером Chrome необходима дополнительная настройка.

Проблема:

В браузере Chrome (и его вариациях) не отображается портал авторизации. Пользователь только видит пустое окно со следующим содержимым:

Заголовок:

HTTP/1.1 407 Authorization Required

Содержимое страницы

<html> <!– please auth via kerberos/NTLM –> </html>

Решение:

Для подробной информации по работе с политиками в браузере, обратитесь к документации по адресу: https://www.chromium.org/administrators/linux-quick-start

  1. В соответствии с инструкцией, нужно создать json-файл в директории managed:

touch /etc/opt/chrome/policies/managed/test_policy.json

Содержимое файла должно быть следующего вида:

{

“AuthServerWhitelist”: “*.usergate.demo”,

“AuthSchemes”: “ntlm,negotiate”

}

“usergate.demo” необходимо заменить на доменное имя вашего домена.

  1. В браузере Chrome открыть страницу политик about:policy.

Вы должны увидеть настройки прописанные в файле на открытой странице:

image44

Если этих строк нет, значит браузеру не удалось загрузить политики из созданного файла. Проверьте права доступа, и другие возможные причины. Обратите внимание, различные браузеры имеют особенности в загрузке политик. Например браузер Chromium на Kali Linux автоматически не загружает описанные политики.

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

2.7. Мультифакторная аутентификация с подтверждением через email

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

  1. Для отправки сообщения у каждого пользователя должен быть указан адрес электронной почты в его локальной учетной записи в UserGate или в доменной учетной записи в Active Directory.

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

image45

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

image46

  1. Создадим профиль оповещения по электронной почте, для этого перейдем в Библиотеки – Профили оповещения, нажмем кнопку Добавить – Добавить профиль оповещения SMTP и в свойствах профиля SMTP внесем следующие настройки:

image47

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

Если проверочное письмо дошло на указанный адрес, сохраним настройки нажав на кнопку Сохранить.

  1. Для примера авторизации мы будем использовать авторизацию пользователей домена AD.

Добавим сервер авторизации.

Перейдем в раздел Пользователи и устройства – Серверы авторизации, нажмем кнопку Добавить – Добавить LDAP коннектор.

В свойствах коннектора LDAP внесем следующие настройки:

Вкладка Настройки

Название – произвольное название сервера авторизации.

Доменное имя LDAP или IP-адрес – IP-адрес сервера контроллера домена.

Bind DN («логин») – внесем доменного пользователя в формате DOMAINusername или username@domain для подключения к серверу LDAP. Данный пользователь уже должен быть заведен в домене.

Пароль – пароль пользователя для подключения к домену.

image48

Вкладка Домены LDAP

Нажмем кнопку Добавить и внесем доменное имя LDAP:

image49

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

image50

Сохраним настройки LDAP коннектора нажав на кнопку Сохранить.

  1. Создадим профиль для мультифакторной аутентификации.

Перейдем в раздел Пользователи и устройства – Профили MFA нажмем на кнопку Добавить – MFA через email и в свойствах профиля MFA внесем следующие настройки:

Название – произвольное название профиля MFA.

Профиль отправки MFA – выберем ранее созданный профиль оповещения по электронной почте.

От – внесем адрес электронной почты пользователя, указанного в профиле оповещения MFA

Тема – Тема в письме

Содержимое – Тело письма.

image51

Сохраним настройки профиля MFA нажав на кнопку Сохранить.

  1. Создадим профиль авторизации.

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

Название – внесем произвольное название профиля авторизации.

Профиль MFA – Выберем ранее созданный профиль MFA.

image52

Добавим ранее созданный LDAP коннектор, нажмем на кнопку Добавить – Сервер LDAP/Active Directory: kraftech.ru

image53

Сохраним настройки профиля авторизации нажав на кнопку Сохранить.

  1. Создадим профиль для Captive-портала.

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

Перейдем в раздел Пользователи и устройства – Captive-профили, нажмем на кнопку Добавить и в свойствах captive-профиля внесем следующие настройки:

Название – внесем произвольное название captive-профиля.

Шаблон страницы авторизации – Выберем шаблон «Captive portal user auth (RU)».

Метод идентификации – Выберем запоминать IP-адрес.

Профиль авторизации – Выберем ранее созданный профиль авторизации.

Если для авторизации пользователей мы используем LDAP коннектор, можно активировать свойство «Предлагать выбор домена AD/LDAP на странице авторизации».

image54

Сохраним настройки captive-профиля нажав на кнопку Сохранить.

  1. Создадим правило Captive-портала.

Перейдем в раздел Пользователи и устройства – Captive-портал, нажмем на кнопку Добавить и в свойствах правила captive-портала внесем следующие настройки:

Название – внесем произвольное название captive-портала.

Captive-профиль – выберем ранее созданный Captive-профиль.

Вкладки Источник, Назначение, Категории, URL, Время, можно настраивать для задания дополнительных условий выполнения правила. Правила применяются сверху вниз в том порядке, в котором совпали условия, указанные в правиле. Для срабатывания правила необходимо, чтобы совпали все условия, указанные в параметрах правила.

image55

Сохраним настройки правила captive-портал нажав на кнопку Сохранить.

  1. Настоим DNS для доменов auth.captive и logout.captive.

Служебные доменные имена auth.captive и logout.captive используется UserGate для авторизации пользователей. Если клиенты используют в качестве DNS-сервера сервер UserGate, то ничего делать не надо. В противном случае необходимо прописать в качестве IP-адреса для этих доменов IP-адрес интерфейса сервера UserGate, который подключен в клиентскую сеть.

  1. Проверим работу мультифакторной авторизации.

В браузере пользователя перейдем на сайт ya.ru. Появилась страница авторизации captive-портала:

image56

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

image57

image58

После ввода кода в окне авторизации, откроется запрошенный сайт – ya.ru

2.8. Мультифакторная аутентификация с подтверждением через одноразовые временные пароли (TOTP)

Рассмотрим пример настройки двухфакторной аутентификации с подтверждением (второй фактор аутентификации) кодом TOTP.

  1. Для примера авторизации мы будем использовать авторизацию пользователей домена AD.

Добавим сервер авторизации.

Перейдем в раздел Пользователи и устройства – Серверы авторизации, нажмем кнопку Добавить – Добавить LDAP коннектор.

В свойствах коннектора LDAP внесем следующие настройки:

Вкладка Настройки

Название – произвольное название сервера авторизации.

Доменное имя LDAP или IP-адрес – IP-адрес сервера контроллера домена.

Bind DN («логин») – внесем доменного пользователя в формате DOMAINusername или username@domain для подключения к серверу LDAP. Данный пользователь уже должен быть заведен в домене.

Пароль – пароль пользователя для подключения к домену.

image59

Вкладка Домены LDAP

Нажмем кнопку Добавить и внесем доменное имя LDAP:

image60

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

image61

Сохраним настройки LDAP коннектора нажав на кнопку Сохранить.

  1. Создадим профиль для мультифакторной аутентификации.

Перейдем в раздел Пользователи и устройства – Профили MFA нажмем на кнопку Добавить – MFA через TOTP и в свойствах профиля MFA внесем следующие настройки:

Название – произвольное название профиля MFA.

Инициализация TOTP – выберем для примера Показать ключ на странице captive-портала

Показывать QR-код – для возможности сканирования кода.

image62

Сохраним настройки профиля MFA нажав на кнопку Сохранить.

  1. Создадим профиль авторизации.

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

Название – внесем произвольное название профиля авторизации.

Профиль MFA – Выберем ранее созданный профиль MFA.

image63

Добавим ранее созданный LDAP коннектор, нажмем на кнопку Добавить – Сервер LDAP/Active Directory: kraftech.ru

image64

Сохраним настройки профиля авторизации нажав на кнопку Сохранить.

  1. Создадим профиль для Captive-портала.

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

Перейдем в раздел Пользователи и устройства – Captive-профили, нажмем на кнопку Добавить и в свойствах captive-профиля внесем следующие настройки:

Название – внесем произвольное название captive-профиля.

Шаблон страницы авторизации – Выберем шаблон «Captive portal user auth (RU)».

Метод идентификации – Выберем запоминать IP-адрес.

Профиль авторизации – Выберем ранее созданный профиль авторизации.

Если для авторизации пользователей мы используем LDAP коннектор, можно активировать свойство «Предлагать выбор домена AD/LDAP на странице авторизации».

image65

Сохраним настройки captive-профиля нажав на кнопку Сохранить.

  1. Создадим правило Captive-портала.

Перейдем в раздел Пользователи и устройства – Captive-портал, нажмем на кнопку Добавить и в свойствах правила captive-портала внесем следующие настройки:

Название – внесем произвольное название captive-портала.

Captive-профиль – выберем ранее созданный Captive-профиль.

Вкладки Источник, Назначение, Категории, URL, Время, можно настраивать для задания дополнительных условий выполнения правила. Правила применяются сверху вниз в том порядке, в котором совпали условия, указанные в правиле. Для срабатывания правила необходимо, чтобы совпали все условия, указанные в параметрах правила.

image66

Сохраним настройки правила captive-портал нажав на кнопку Сохранить.

  1. Настоим DNS для доменов auth.captive и logout.captive.

Служебные доменные имена auth.captive и logout.captive используется UserGate для авторизации пользователей. Если клиенты используют в качестве DNS-сервера сервер UserGate, то ничего делать не надо. В противном случае необходимо прописать в качестве IP-адреса для этих доменов IP-адрес интерфейса сервера UserGate, который подключен в клиентскую сеть.

  1. Проверим работу мультифакторной авторизации.

В браузере пользователя перейдем на сайт ya.ru. Появилась страница авторизации captive-портала:

image67

После ввода логина и пароля появится окно для ввода дополнительного кода аутентификации:

image68

Получить этот код можно установив специальное приложение либо расширение в браузер, которое умеет генерировать код на основе алгоритма TOTP. Для примера мы установим расширение «Авторизация» в браузер Google Chrome:

image69

Добавим в расширение ключ инициализации TOTP:

image70

Расширение браузера Chrome «Авторизация» нам выдаст временный код для авторизации на портале.

После ввода кода в окне авторизации, откроется запрошенный сайт ya.ru

Для повторной авторизации на Captive портале необходимо снова воспользоваться расширением «Авторизация» где будет уже сгенерированный новый код для нашего TOTP.

2.9. Авторизация пользователей SSL VPN портала по сертификату

Дополнительно к авторизации пользователей SSL VPN портала по логину и паролю существует возможность настроить “прозрачную” авторизацию этих пользователей по SSL сертификату.

Для этого, в дополнение к базовой настройке SSL VPN портала, необходимо проделать следующие шаги:

  1. Для каждого пользователя выпустить SSL сертификат, в котором указаны следующие параметры применения ключа – Digital Signature, Key Encipherment и Data Encipherment.

Если для выпуска сертификата используется приложение XCA, достаточно выбрать в нём и применить шаблон HTTPS_client.

Удостоверяющий центр, которым подписан сертификат пользователя не имеет значения.

В том числе работают и самоподписанные сертификаты.

  1. Импортировать в браузер каждого пользователя, выписанный для него сертификат вместе с закрытым ключём (обычно, формат файла .p12).

  2. Импортировать в UserGate сертификаты всех пользователей (без закрытого ключа, обычно, формат файла .cer).

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

  1. В настройках SSL VPN портала произвести следующие изменения:

2.10. Установка и настройка агента терминального сервера UserGate

Для пользователей, работающих на операционной системе Windows, существует еще один

способ идентификации – использовать специальный агент авторизации. Агент представляет

собой сервис, который передает на сервер UserGate информацию о пользователе, его имя и

IP-адрес, соответственно, UserGate будет однозначно определять все сетевые подключения

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

2.10.3. Установка агента терминального сервера UserGate

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

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

Минимальные достаточные для установки агента данные составляют IP-адрес устройства и пароль для подключения к устройству.

Так как ПО распространяется в виде MSI пакета, его возможно установить и сконфигурировать в автоматическом режиме. Например, ПО можно распространить применяя групповые политики Microsoft Active Directory.

Так же ПО можно установить и сконфигурировать запустив утилиту Windows Installer msexec.exe.

Пример команды для скрытой автоматической установки ПО:

msiexec.exe /log install.log -i \file-serverTerminalServerAgent-x64.msi /quiet SERVER_ADDRESS=[ip-address] UTM_PASSWORD=[password]

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

Ключ /quiet скрывает графический интерфейс установщика ПО. Иными словами установка ПО произойдет в скрытом режиме.

Далее указываются два обязательных параметра конфигурации в формате КЛЮЧ=ЗНАЧЕНИЕ. Таким образом мы сообщаем установщику IP-адрес устройства UserGate и регистрационный пароль.

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

image72

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

image73

Виртуализация¶

3.1. Развертывание образа UserGate на Hyper-V

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

  1. Первым делом необходимо скачать образ с нашего официального сайта.

image74

  1. Затем распакуем файл utm-hyperv.zip.

extract_zip

  1. Проверим сетевые интерфейсы на хостовой машине с Hyper-V.

Network_adapters

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

Virt_sw_add

По умолчанию в UserGate имеются четыре зоны Management, Trusted, Untrusted и DMZ.

Virt_sw_4

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

Virt_sw_4

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

  1. Создадим новую виртуальную машину.

New_VM

VM_create_p1

  1. Задаем имя виртуальной машины и папку, в которой будут храниться данные.

Create_VM_p2

  1. Увеличьте размер оперативной памяти виртуальной машины. Используя свойства виртуальной машины, установите минимум 8Gb и добавьте по 1Gb на каждые 100 пользователей.

Create_VM_p4

  1. Указываем подключение к первому созданному нами виртуальному коммутатору.

  2. Выбираем виртуальный жесткий диск из папки, в которую мы распаковали скачанный файл utm-hyperv.zip.

VM_VHD

  1. Виртуальная машина создана осталось ее настроить.

VM_summary

  1. Установим два виртуальных процессора (Количество процессоров определяем в зависимости от количества пользователей и ресурсов вашего сервера)

V_CPU

  1. Создадим четыре сетевых адаптера и подключим их к созданным ранее виртуальным коммутаторам.

Net_2

Net_2_1

Net_3

Net_4

  1. Увеличьте размер диска виртуальной машины. Размер диска по умолчанию составляет 20Gb, что недостаточно для хранения всех журналов и настроек. Используя свойства виртуальной машины, установите размер диска в 100Gb или более. Рекомендованный размер – 300Gb.

  2. Отключите службы интеграции в настройках созданной виртуальной машины.

  3. Теперь виртуальная машина настроена, и мы запускаем ее, нажав на Start.

Start_VM

За стартом можно наблюдать, подключившись к виртуальной консоли.

CLI_1

  1. Во время первой загрузки выполнится процедура Factory reset. Во время этого шага UserGate настраивает сетевые адаптеры и увеличивает размер раздела на жестком диске до полного размера диска, увеличенного в предыдущих пунктах.

  2. После перезагрузки, если в сети, подключенной к первому виртуальному коммутатору (Management) и соответственно интерфейсу eth0 есть DHCP сервер, в приглашении мы увидим адрес и порт, для управления через веб-консоль.

image92

  1. Если DHCP сервера нет, то необходимо через консоль в командной строке задать адрес для интерфейса. Заходим под логином Admin, пароль utm. С помощью команды

iface config -name eth0 -ipv4 192.168.30.66/24 -enabled true -mode static

присваиваем адрес интерфейсу eth0, который подключен первому виртуальному коммутатору (Management) и соответственно к первому сетевому адаптеру.

image93

  1. Дальнейшую настройку производим, подключившись через веб консоль по заданному адресу. На предупреждение о небезопасном соединении нажимаем на ADVANCED. Здесь приведен пример для браузера Chrome английская версия, для других браузеров картинка немного измениться.

HTTPS_1

Затем нажимаем на Proceed.

HTTPS_2

  1. Выбираем язык установки и часовой пояс

Lang_choice

Timezone

  1. Принимаем Лицензионное соглашение.

image98

  1. Задаем логин и пароль для администратора.

Passwd_set

И перед нами открывается веб-консоль продукта.

Web_console

  1. Настраиваем доступ в интернет для последующей регистрации и работы продукта.

Интерфейс eth0 у нас уже имеет IP-адрес и ему назначена зона Management.

  1. Назначаем IP-адрес для интерфейса eth1, устанавливаем зону Trusted и включаем интерфейс eth1.

eth1_page2

eth1_p1

  1. Назначаем IP-адрес для интерфейса eth2, устанавливаем зону Untrusted и включаем интерфейс eth2. Для интерфейса eth2 укажем получение адреса по DHCP

eth2_page1

eth2_page2

  1. Назначаем IP-адрес для интерфейса eth3, устанавливаем зону DMZ и включаем интерфейс eth3.

eth3_page1

eth3_page2

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

Для интерфейса eth0 также адрес и шлюз выданы DHCP сервером. В итоге мы видим, что у нас два шлюза.

Two gateway

  1. Чтобы была возможность подключаться через интерфейс eth0 для управления UserGate с компьютеров в сети 192.168.30.0/24 необходимо сначала добавить маршрут в эту сеть через шлюз, который был выдан для интерфейса eth0 DHCP сервером.

Route

  1. Оставляем один шлюз по умолчанию для выхода в интернет.

Gateway_1

  1. Устанавливаем адрес DNS сервера.

DNS

  1. Проверяем корректность сетевых настроек подключившись через виртуальную CLI консоль и набрав команду ping ya.ru. Если команда выполняется ping проходит, значит мы все правильно настроили и можно приступать к регистрации продукта.

test_ping

  1. Регистрируем продукт, для этого нажимаем на “незарегистрированная версия”, вводим Пин-код продукта и заполняем регистрационные данные (латинскими буквами).

registration1

registration2

registration3

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

  1. Посмотреть версию баз и ход обновления можно на вкладке Дашборд. Нажмем кнопку проверить обновления.

image115

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

2. Создание сертификатов с помощью программы OpenSSL¶

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

# mkdir /root/ca

# cd /root/ca

# mkdir certs crl newcerts private

# chmod 700 private

# touch index.txt

  1. Сгенерируем приватный ключ.

# openssl genrsa -out /root/ca/private/ca_key.pem 2048

  1. Создадим сертификат CA для этого приватного ключа

# openssl req -new -x509 -days 3650 -key /root/ca/private/ca_key.pem -out /root/ca/certs/ca.crt

Вывод команды

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter ‘.’, the field will be left blank.

4.2. Распространение сертификатов на клиентские компьютеры с помощью групповой политики¶

На контроллере домена в лесу организации партнера по учетным записям запустите оснастку Управление групповыми политиками.

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

Щелкните правой кнопкой мыши-объект групповой политики и выберите команду изменить.

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

На странице Добро пожаловать на страницу мастера импорта сертификатов нажмите кнопку Далее.

На странице импортируемый файл введите путь к соответствующим файлам сертификатов (например C:c.cer), а затем нажмите кнопку Далее.

На странице хранилище сертификатов щелкните поместить все сертификаты в следующее хранилище, а затем нажмите кнопку Далее.

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

Межсетевое экранирование и правила пропускной способности¶

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

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

Пример реализации.

В компании настроена зона Trusted, назначенная для интерфейса, через который пользователи локальной сети получают доступ в интернет.

Есть зона DMZ, в которой расположены различные сервера компании, используемые для предоставления ресурсов пользователям

локальной сети.

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

  1. Создаем правило с полосой пропускания 100Kbps для требуемой группы пользователей и в качестве Зоны назначения указываем Trusted.

Весь трафик, как из зоны Untrusted, так из зоны DMZ в зону Trusted будет ограничиваться данным правилом.

  1. Для того, чтобы трафик от серверов компании в зоне DMZ к данной группе пользователей из зоны Trusted не ограничивался, в данном правиле в качестве Адреса источника указываем список IP-адресов серверов и в правиле ставим галочку инвертировать.

1. Пример настройки пропускной способности для разных зон и пользователей¶

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

Пример реализации.

В компании настроена зона Trusted, назначенная для интерфейса, через который пользователи локальной сети получают доступ в интернет.

Есть зона DMZ, в которой расположены различные сервера компании, используемые для предоставления ресурсов пользователям

локальной сети.

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

  1. Создаем правило с полосой пропускания 100Kbps для требуемой группы пользователей и в качестве Зоны назначения указываем Trusted.

Весь трафик, как из зоны Untrusted, так из зоны DMZ в зону Trusted будет ограничиваться данным правилом.

  1. Для того, чтобы трафик от серверов компании в зоне DMZ к данной группе пользователей из зоны Trusted не ограничивался, в данном правиле в качестве Адреса источника указываем список IP-адресов серверов и в правиле ставим галочку инвертировать.

Взаимодействие со сторонними системами¶

9.1. Перенос учетных данных пользователей с UserGate Proxy & Firewall на UserGate 5.0.

Скрипт написан на языке Python, поэтому для его запуска, необходимо скачать и установить интерпретатор с официального сайта https://python.org/downloads/ (в среде Windows)

В среде Linux откройте консоль (ctrl alt t). Введите в консоли:

python3

Если увидите приветствие вида:

Python 3.4.3 (default, Nov 17 2022, 01:08:31)

[GCC 4.8.4] on linux

Type “help”, “copyright”, “credits” or “license” for more information.

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

sudo apt-get install python3

Для корректной работы скрипта, приложенного к данной заметке, в него необходимо внести изменения. Откройте файл любым текстовым редактором.

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

!Внимание: часть скрипта ниже только пример.

configuration options ####################################

UTM_SERVER = ‘192.168.30.134’ – ip адрес

UTM_ADMIN = ‘Admin’ – логин

UTM_PASSWORD = ‘хххххх’ – пароль

STOP_LOGINS = [‘NETWORK SERVICE’, ‘LOCAL SERVICE’, ‘SYSTEM’]


После внесения изменений, сохраните скрипт. В ту же директорию необходимо положить файл “C:programdataentensysusergate6config.cfg”, который необходимо скопировать с компьютера, на котором установлен UserGate Proxy & Firewall.

Перед запуском скрипта необходимо открыть разрешение для управления доступом к XML-RPC на зонах

После этого в свойствах зоны назначенной интерфейсу, адрес которого указываем в скрипте открываем доступ XML-RPC

Selection_404.jpg

Запускаем скрипт:

root@nn:~/temp$ python3 users-migration.py

В случае успешной работы скрипта:

Skipping user NETWORK SERVICE

Skipping user LOCAL SERVICE

Skipping user SYSTEM

All done.

root@nn:~/temp$

После выполнения скрипта необходимо на зоне запретить доступ к XML-RPC

Если в скрипт были внесены не корректные данные, то будут ошибки вида:

FATAL: XML-RPC error: <Fault 3: ‘Invalid method format’> – не корректные данные пользователя, либо

OSError: [Errno 113] No route to host – не корректный IP адрес хоста UserGate.

9.2. Настройка SNMP мониторинга с помощью ZABBIX

Права доступа

Права доступа выдаются клиенту в виде scope. Scope – это параметр, который состоит из разделённых пробелами строк — scope-token.

Каждый из scope-token представляет определённые права, выдающиеся клиенту. Например, scope-token doc_read может предоставлять доступ на чтение к какому-то документу на resource server, а employee — доступ к функционалу приложения только для работников фирмы. Итоговый scope может выглядеть так: email doc_read employee.

В OAuth 2.0 мы сами создаём scope-token, настраивая их под свои нужды. Имена scope-token ограничиваются только фантазией и двумя символами таблицы ASCII — ” и .

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

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

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

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

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

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

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

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

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

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

Проблемы

Первая версия Auth — часть монолита. Он использует свой собственный протокол общения с сервисами. Такая «схема» была необходима в тот момент, но за несколько лет работы проявились проблемы.

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

Dodo IS зависит от Auth. В старой реализации внешние сервисы обращаются к Auth при каждом действии пользователя, чтобы валидировать данные о нём. Настолько сильная привязка может привести к остановке работы всей Dodo IS, если Auth «приляжет» по какой-то причине.

Auth зависит от Redis. Притом достаточно сильно — неисправность работы Redis’а приведёт к падению Auth’а. Мы используем Azure Redis, для которого заявленный SLA 99,9%. Это значит, что сервис может быть недоступен до 44 минут в месяц. Такие простои не позволительны.

Текущая реализация Auth использует свой протокол аутентификации, не опираясь на стандарты. В большинстве своих сервисов мы используем C# (если говорим о backend) и у нас нет проблем с поддержкой библиотеки для нашего протокола. Но если вдруг появятся сервисы на Python, Go или Rust, разработка и поддержка библиотек под эти языки потребует дополнительных затрат времени и принесет дополнительные сложности.

Текущий Auth использует схему Roles Based Access Control, которая базируется на ролях. Обычно с ролью выдаётся полный доступ к определённому сервису, вместо привязки к конкретному функционалу. Например, в пиццериях есть заместители управляющего, которые могут вести определенные проекты: составлять графики или учитывать сырьё.

Проблемы подтолкнули к тому, чтобы спроектировать и написать новую версию Auth. На старте проекта мы потратили 3 недели только на изучение стандартов авторизации и аутентификации OAuth 2.0 и OpenID Connect 1.0. 

Примечание. Утрированно, статья — это пересказ RFC, который приходилось перечитывать несколько раз, чтобы понять, что происходит вокруг. Здесь я постарался уйти от этой сложности и рассказать всё максимально просто, структурировано, кратко и без описания сложных вещей, например, какие символы может содержать в себе ответ сервиса.

Пути решения

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

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

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

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

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

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

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

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

Регистрация клиента

Способ регистрации клиента, например, ручной или service discovery, вы выбираете сами, в зависимости от

фантазии

конкретной реализации. Но при любом способе при регистрации, кроме ID клиента, должны быть обязательно указаны 2 параметра: redirection URI и client type.

Redirection URI — адрес, на который отправится владелец ресурса после успешной авторизации. Кроме авторизации, адрес используется для подтверждения, что сервис, который обратился за авторизацией, тот, за кого себя выдаёт.

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

Токены

Токен в OAuth 2.0 — это строка, непрозрачная для клиента. Обычно строка выглядит как случайно сгенерированная — её формат не имеет значения для клиента. Токен — это ключ доступа к чему-либо, например, к защищённому ресурсу (access token) или к новому токену (refresh Token).

У каждого токена своё время жизни. Но у refresh token оно должно быть больше, т.к. он используется для получения access token. Например, если срок жизни access token около часа, то refresh token можно оставить жить на целую неделю. 

Refresh token опционален и доступен только для confedential клиентов. Пользуясь опциональностью токена, в некоторых реализациях время жизни access token сделано очень большим, а refresh token вообще не используется, чтобы не заморачиваться с обновлением.

За access token закреплён определённый набор прав доступа, который выдаётся клиенту во время авторизации. Давайте разберёмся, как выглядят права доступа в OAuth 2.0.

Вместо вывода


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

Если хотите погрузиться в тематику детальнее, то рекомендую в RFC 6749 (для OAuth 2.0) и RFC 8628 (для Device Flow). Кроме того, следить за актуальными версиями RFC можно на ресурсе, посвящённому OAuth.

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

Полезные ссылки:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *